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

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

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

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

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

Опасность — использовать этот инструмент не для той работы. Проектное управление, применённое к развивающейся цифровой услуге, порождает патологию «построил и бросил», описанную в теме 5.0 — Работа, ведомая продуктом. Эта тема объясняет, где работа, ведомая проектами, — верный инструмент и где начинаются её пределы. Она стоит рядом с темой 5.2 — Работа, ведомая программами, координирующей несколько проектов, и темой 5.3 — Управление корпоративным портфелем и проектами (EPPM), выбирающей между этими инструментами.

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

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

Железный треугольник (объём, время, стоимость). Классическая модель ограничений: объём, график и бюджет взаимозависимы, а качество зависит от того, как они сбалансированы. Измените одно — и вы меняете другие; контроль проекта в значительной мере — дисциплина прозрачного управления этим компромиссом.

PRINCE2 (PRojects IN Controlled Environments). Структурированный проектный метод правительства Великобритании, широко используемый в NHS и государственном секторе. Он построен на принципах (непрерывное деловое обоснование, определённые роли, управление по стадиям, управление по исключениям, фокус на продуктах, учёба на опыте, адаптация к среде) и организует работу в контролируемые стадии с проектным советом, дающим направление.

PMI / PMBOK. Guide to the Project Management Body of Knowledge от Project Management Institute — доминирующий международный аналог, строящий проектную работу вокруг областей результативности и принципов, а не предписанного стадийного процесса. PRINCE2 и PMBOK — взаимодополняющие линзы на одну дисциплину.

Бизнес-кейс. Документ, оправдывающий проект: проблема, оценённые варианты, ожидаемые выгоды, затраты и риски. В PRINCE2 бизнес-кейс живой: он проверяется на каждой границе стадии, и если непрерывное обоснование исчезает, верное решение — остановиться. В британских государственных органах он обычно структурируется как Five Case Model (стратегический, экономический, коммерческий, финансовый, управленческий) HM Treasury.

Шлюзы стадий. Проект PRINCE2 делится на управленческие стадии, разделённые шлюзами решений. На каждой границе проектный совет принимает осознанное решение «стоп/продолжать»: рассматривает прогресс и бизнес-кейс, утверждает план следующей стадии и выделяет ресурсы только на эту стадию. Так совет сохраняет контроль и не бросает хорошие деньги вслед за плохими.

Журнал RAID. Единый реестр рисков, допущений, проблем и зависимостей (Risks, Assumptions, Issues, Dependencies) — основной контрольный артефакт менеджера проекта. RAID делает неопределённость видимой и управляемой: риски — то, что может случиться, проблемы — то, что уже случилось, допущения — то, на что опирается план, а зависимости — то, что плану нужно извне.

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

1. Начинайте с честного бизнес-кейса и держите его живым. Используйте признанную структуру (Five Case Model в британских государственных органах), чтобы оценивать реальные варианты, а не единственный заранее предрешённый ответ. Затем относитесь к бизнес-кейсу как к живому документу, пересматриваемому на каждом шлюзе стадии: непрерывное деловое обоснование — первый принцип PRINCE2, а его утрата — законная причина остановиться.

2. Определяйте объём точно и контролируйте его изменения. Ценность проекта — в ясном, ограниченном определении «готово». Согласуйте объём, зафиксируйте его базовую линию и пропускайте каждое предлагаемое изменение через процесс контроля изменений, чтобы расползание объёма не съело тихо бюджет и график.

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. После закрытия и роспуска проверяет ли кто-нибудь, материализовались ли выгоды из бизнес-кейса, и узнали бы мы, если нет? Бизнес-кейс обещает выгоды, оправдывающие расходы, но работа, ведомая проектами, естественно заканчивается запуском и освобождением команды, так что момент истины — снизила ли миграция риск, затраты или улучшила ли уход — обычно наступает, когда все уже ушли и никто не подотчётен за подтверждение. Это остро важно в общественном здравоохранении и уходе, где деньги закреплены за бизнес-кейсом Five Case, о котором парламенту, аудиторам и советам говорили, что он даст конкретные результаты, но реализация выгод — шаг, чаще всего пропускаемый, потому что проекта, который им владел бы, больше нет. Обсуждение должно решить, кто наследует отслеживание выгод при закрытии проекта, на какой срок и относительно каких базовых измерений, которые нужно зафиксировать до запуска, иначе они потеряны. Подумайте о недавно завершённом проекте и прямо спросите, проверял ли кто-нибудь с тех пор его обещанные выгоды и дошла бы недостача когда-нибудь до совета, одобрившего его. Честный ответ закрепляет владение выгодами после закрытия за постоянной функцией, а не за распущенной командой, фиксирует базовую линию, пока проект ещё жив, и готов записать, что проект поставил результат в срок и в бюджет, но не дал ценности, оправдавшей его.

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

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

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

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

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

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

Стартап#

Небольшая цифровая компания здравоохранения редко ведёт формальные проекты PRINCE2, но подлинно конечная работа всё равно появляется: разовая миграция данных на новую облачную платформу, рывок по сертификации Cyber Essentials или DTAC, устранение результатов пентеста перед крупным контрактом NHS. Стартап ведёт их как лёгкие, ограниченные по времени усилия с названным владельцем и ясным определением «готово», заимствуя дисциплину (фиксированный объём, дата окончания, go/no-go) без церемонии (без формального проектного совета, без пятистадийных шлюзов). Финансирование на деле — внимание основателей и запас хода, так что риск в том, что конечная работа зажимается между продуктовыми спринтами и никогда не закрывается. Исправление — назвать единственного владельца и жёсткий срок и считать сертификацию или миграцию сделанной и закрытой, а не вечно «в процессе».

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

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или клиника на одной площадке — встречает работу, ведомую проектами, как редкие, но неизбежные события: смена поставщика клинической системы, переход на новую платформу управления практикой или замена устройств в конце срока службы до истечения поддержки. У организации есть реальные пациенты и текущая деятельность, но нет выделенной проектной или ИТ-функции, так что «проектная команда» обычно — управляющий практикой или зарегистрированный менеджер, делающий это наряду с основной работой, часто опираясь на входящего поставщика в проведении миграции. Дисциплина, переживающая встречу с этой реальностью, — лёгкое ядро: ясное конечное состояние, зафиксированный объём, чтобы поставщик тихо его не расширил, названный подотчётный человек и проверенный откат перед любым переключением, затрагивающим записи пациентов. Ловушка — передать на аутсорс не только работу, но и суждение: принять дату запуска и заверения об отображении данных от поставщика без независимой проверки, потому что те же обязанности клинической безопасности и управления информацией (DCB0160, DPIA) применяются независимо от того, как мала организация. Исправление — сохранить решение go/no-go и критерии приёмки внутри, даже когда все остальные пары рук принадлежат вендору.

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

Крупный траст NHS или интегрированная система ухода (ICS) — место, где работа, ведомая проектами, чувствует себя как дома: замены EPR, Wi-Fi по всему хозяйству, выходы из ЦОДов и переключения несут жёсткие договорные обрывы и обрывы безопасности пациентов. Здесь оправдан весь аппарат — бизнес-кейс Five Case, совет PRINCE2 с названным исполнительным директором/SRO, старшим пользователем и старшим поставщиком, управленческие стадии с настоящими шлюзами и живой журнал RAID, — потому что суммы велики, подверженность безопасности остра, а внутренний аудит и совет будут проверять расходы. Характерный провал в таком масштабе — безразборное применение того же управления и к живым услугам (тема 5.0 — Работа, ведомая продуктом), и к конечной работе, поэтому важен портфельный взгляд (тема 5.3 — Управление корпоративным портфелем и проектами), направляющий каждую работу в верный режим. Клиническая безопасность (DCB0160) и проверенный откат — обязательные результаты шлюзов, а не опциональные дополнения.

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

В национальном или крупном проектном масштабе работа, ведомая проектами, находится внутри режима гарантий правительства: Infrastructure and Projects Authority проводит шлюзовые обзоры, Green Book и Five Case Model HM Treasury управляют бизнес-кейсом, а крупнейшие проекты входят в Government Major Projects Portfolio с опубликованной подотчётностью перед парламентом и National Audit Office. Подотчётность предельно публична — ответственный руководитель лично подотчётен и может быть вызван в специальный комитет, — так что шлюзы стадий и оценки вариантов — контроль законного уровня, а не театр. Финансирование выделяется траншами по одобренным бизнес-кейсам, а аппетит к риску низок, потому что провал становится новостью на первой полосе. Настоящая ценность дисциплины здесь — полномочие остановить или сузить провальный проект до того, как он станет публичным списанием.

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

• Проектное управление развивающейся услугой. Применение управления с фиксированным объёмом и роспуском в конце к живому цифровому продукту порождает патологию бросания. Исправление: используйте работу, ведомую продуктом (тема 5.0), там, где услуга продолжается.
• Бизнес-кейс как разовый билет к финансированию. Написан один раз, чтобы открыть деньги, и никогда не пересматривается. Исправление: пересматривайте на каждом шлюзе стадии; будьте готовы остановиться.
• Шлюзы стадий-штампы. Шлюзы, никогда не говорящие «стоп», не дают контроля. Исправление: сделайте остановку или перепланирование реальным вариантом совета и пользуйтесь им.
• Расползание объёма без контроля изменений. Неконтролируемые добавления взрывают время и стоимость. Исправление: зафиксируйте базовую линию объёма и пропускайте каждое изменение через контроль изменений.
• Нет плана перехода в услугу. Проект заканчивается, и никто не владеет результатом. Исправление: согласуйте принимающую команду и модель поддержки до запуска.
• RAID как картотека. Журнал, который пишут и никогда не используют. Исправление: регулярно пересматривайте RAID и эскалируйте по исключениям.
• Никогда не закрываются по-настоящему. Проекты-зомби, потребляющие ресурс без конца. Исправление: осознанное закрытие с приёмкой, передачей и зафиксированными уроками.

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

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

• Работа действительно конечна, с определённым объёмом и конечным состоянием (не продолжающаяся услуга)?
• Есть живой бизнес-кейс (Five Case Model), пересматриваемый на каждом шлюзе стадии?
• Объём зафиксирован, с работающим процессом контроля изменений?
• Стадии работы определены, и каждая заканчивается настоящим шлюзом решения «стоп/продолжать»?
• Роли проектного совета ясны — исполнительный директор/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 (Five Case Model / Green Book).
• Infrastructure and Projects Authority (IPA), Cabinet Office — руководство по гарантиям и шлюзовым обзорам для крупных проектов.
• Стандарт клинической безопасности NHS Digital DCB0160 (внедрение ИТ-систем здравоохранения).
• 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