Как нечеткие цели на старте проекта и плохая работа с заинтересованными сторонами привели к переделкам на миллионы долларов. Часть 1.

Иногда бывает полезно посмотреть на чужой (неудачный) опыт, чтобы не повторить чужие ошибки.

Предлагаем вам разбор как раз такого кейса.

Удобнее получить информацию в сжатой форме и графике? Тогда смотрите этот же кейс в формате презентации и в записи:

Скачать презентацию

Смотреть видео

А тех, кто хочет избежать проблем со своими проектами на старте, приглашаем на курс от наших партнеров из Проектной ПРАКТИКИ:

Подробнее

Одним из известных примеров провала проекта, связанного с нечетким пониманием целей и несогласованностью ожиданий заинтересованных сторон, является проект Healthcare.gov.

Healthcare.gov - портал, созданный для реализации программы доступного здравоохранения в США (программа Obamacare).

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

Давайте попробуем погрузиться в кейс, проанализируем, что было сделано не так (с точки зрения проектного управления), с какими сложностями столкнулся проект и к чему это привело. И мы увидим, что многое не было проработано на старте проекта – на этапе его запуска. Анализ будет полезен не только для ИТ проектов, но для любых масштабных технологических и не только проектов, затрагивающих государственную и общественную сферу.

Краткое резюме кейса

Сайт Healthcare.gov был создан администрацией президента Барака Обамы в рамках реформы здравоохранения, известной как Patient Protection and Affordable Care Act, или Obamacare.

Основная задача проекта — помочь гражданам США получить доступ к медицинскому страхованию. На сайте можно выбрать и купить подходящий страховой пакет онлайн.

К январю 2014 года все жители США должны были иметь доступ к недорогой и доступной медицинской страховке в соответствии с законом 2010 года. Healthcare.gov должен был упростить этот процесс и сделать его более доступным.

И так, проект:

• Создавался на основании закона 2010 года Patient Protection and Affordable Care Act(PPACA)

• Должен был обеспечить доступность медицинской страховки и снижение стоимости медицинского обеспечения для граждан.

• Охватывать поддержку как минимум 36 штатов США

• В разработке участвовало 47 подрядчиков.

• Старт проекта – весна (март) 2010, окончание проекта – конец (октябрь-декабрь) 2013 года.

• Изначальный заявленный бюджет в 2010 году 70 млн. USD, затраты на октябрь 2013 года - 293 млн. USD. Стоимость на декабрь 2013 года - 319 млн. USD.

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

В результате проект Healthcare.gov не оправдал ожиданий и не стал символом реформы здравоохранения. Вместо этого он стал символом технических проблем и неудач, связанных с внедрением Obamacare.

30 июля 2014 года Управление правительственной отчётности США выпустило исследование, в котором сделан вывод, что администрация не обеспечила «эффективное планирование или надзор» в проекте разработки веб-сайта HealthCare.gov.

Что пошло не так?

Healthcare.gov должен был стать удобной платформой, где американцы могли бы сравнивать планы медицинского страхования и регистрироваться для получения услуг. Однако проект столкнулся с рядом серьезных проблем:

•  Большинство пользователей не смогли на зарегистрироваться из-за технических сбоев сразу после запуска в октябре 2013 года.

•  Множество функций, обещанных на этапе разработки, не работали, а интерфейс был непонятным для пользователей.

•   Сайт не выдерживал большого объема пользователей и постоянно «падал».

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

Ключевые выводы: 

1. На старте проекта были нечетко определены цели: На старте не была сформирована ясная концепция проекта, и его цели не были согласованы между различными заинтересованными сторонами, включая правительство и разработчиков.

2.  Были недостаточно хорошо проведены работы с заинтересованными сторонами, и плохо координировалась работа команд: В проекте участвовало большое число государственных организаций с политически ангажированными интересами, а так же более 47 подрядчиков, у которых не было единого плана и общего видения.

3.  Было недостаточно проработано содержания проекта, отсутствовала фокусировка на ключевых функциях: Нечеткость целей усугублялось тем, что содержание проекта было перегружено. Вместо того чтобы сосредоточиться на создании стабильного и минимально жизнеспособного продукта (MVP), проект охватил слишком широкий спектр задач. Что вместе с раскоординацией заинтересованных сторон породило вал проблем. 

В результате технических и управленческих проблем продукт проекта – портал Healthcare.gov -  оказался недееспособным в первые недели после запуска, что вызвало общественное недовольство и потребовало значительных доработок.

Исправление ошибок обошлось в миллионы долларов - на момент старта портала бюджет проекта оценивался в 290 – 319 млн. USD, что превышало стартовый бюджет в 4 с лишним раза. При этом в официальных исследованиях фактически оценки на реализацию портала оценивались еще выше – до 500 – 600 млн. USD.

Репутация проекта и программы Obamacare пострадала.

Этот пример демонстрирует, к чему может привести проект отсутствие четкого понимания целей, плохо сформулированные требования и недостаточная координация.

Анализ показывает, что основные проблемы с проекта Healthcare.gov были заложены в момент запуска.

Вот что именно, с нашей точки зрения, пошло не так.

1. Отсутствие четкого формулирования целей

Цели проекта изначально были слишком широкими и абстрактными: «создать удобный портал для регистрации на страховые планы».

Однако:

•   Не было ясного понимания, какие именно функции сайта являются приоритетными для успешного запуска.

•  Концепция минимально жизнеспособного продукта (MVP) не была проработана. Вместо этого пытались реализовать слишком много функций одновременно.

Как проблема проявлялась на практике?

Функционал сайта Healthcare.gov был сформулирован как инструмент, который должен был предоставить гражданам США удобный доступ к следующим возможностям:

1.  Регистрация пользователей: учетная запись для входа и работы с сайтом.

2. Выбор и сравнение страховых планов: информация о страховых компаниях, планах и их стоимости.

3.  Проверка права на льготы: автоматическое определение права на субсидии или участие в Medicaid.

4.  Обработка заявок и оплата: возможность подачи заявки на страхование и оплаты через сайт.

5.  Управление учетными записями: настройка и обновление данных пользователей.

Что пошло не так?

Реальность: Проблемы с формулировкой целей и функционала.

•  Слишком широкий охват: вместо минимального набора функций для запуска (MVP), сайт был задуман как платформа «всё в одном», которая должна была удовлетворить все возможные запросы пользователей. Такое масштабное видение не было адаптировано к реальным срокам и ресурсам.

•  Нечеткость приоритетов: не было ясно определено, какие функции являются ключевыми для успешного запуска, а какие можно добавить позже. Это привело к попытке реализовать всё сразу, что увеличило сложность.

•  Недостаток фокуса на реальной нагрузке: функционал был спроектирован без учёта предполагаемой нагрузки на серверы, и сайт не смог выдержать наплыв миллионов пользователей в день запуска.

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

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

2. Отсутствие согласования целей между заинтересованными сторонами

Проект включал множество сторон: федеральное правительство, подрядчиков, страховые компании и ИТ-команды.

Однако:

•   Цели и ожидания каждой из сторон сильно различались, и не было единого видения конечного результата.

•  Каждый подрядчик выполнял свои задачи без должной координации, что привело к несогласованности функционала.

Как проблема проявлялась на практике?

В согласовании проекта участвовало большое число заинтересованных сторон, а интересы ключевой стороны – пользователей – были осознанно или неосознанно проигнорированы.

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

•     Белый дом и политические лидеры. Главной задачей администрации Обамы было обеспечить запуск портала Healthcare.gov, как части реализации программы Affordable Care Act (ACA). Политическое руководство настаивало на соблюдении сроков, поставив политические приоритеты выше технических реалий.

•   Министерство здравоохранения и социальных служб (HHS). HHS было ответственным за управление проектом, в частности через Центры по обслуживанию Medicare и Medicaid (CMS), которые играли ключевую роль в разработке сайта. CMS стали центральной точкой для координации технической работы и подрядчиков, но не справились с задачей.

•   Частные подрядчики. К разработке системы было привлечено множество компаний. Они занимались созданием программного обеспечения, серверной инфраструктуры и интерфейсов. Однако подрядчики работали разрозненно и часто без общего видения целей.

•     Штаты и местные органы управления. Участие штатов варьировалось, так как некоторые из них запускали собственные порталы. Однако их требования не всегда учитывались в общей стратегии.

•     Граждане и конечные пользователи. Хотя конечные пользователи (граждане, которые должны были использовать сайт для регистрации медицинских планов) были важной аудиторией, их мнение почти не учитывалось на этапе разработки.

Что пошло не так?

Реальность: отсутствие согласованности в целях и интересах заинтересованных сторон:

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

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

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

•    Краткие сроки без учета сложности. Политическое давление на соблюдение сроков (запуск сайта в 2013 году) превалировало над реалистичной оценкой времени, необходимого для разработки такого сложного проекта. Это говорит о конфликте интересов между политическими целями и техническими возможностями.

•     Отсутствие обратной связи с пользователями. На ранних этапах разработки не было уделено должного внимания обратной связи от конечных пользователей (граждан), что привело к созданию системы, не соответствующей их ожиданиям и нуждам. Это показывает, что цели различных групп заинтересованных сторон (например, чиновников и граждан) не были согласованы.

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

Это ещё не всё! Продолжение следует во второй части статьи.

Читать