ГлавнаяБлогМетодологииКейсы и практика
Система создания ценности в PMBOK 8: как связать проекты со стратегией компании
10.03.2026
~10 мин.
Вступление: почему «успешный» проект не радует
Мы довольно часто заходим в компанию, где отчёты по проектам выглядят прилично: «78% проектов завершены в срок и в бюджет, отклонения в пределах допустимого». На бумаге — успех. В реальности — топ-менеджмент недоволен, стратегия буксует, рынок уезжает вперёд, а в коридорах звучит знакомое: «Мы столько делали, а эффекта почти не видно». Проекты живут своей жизнью, стратегия — своей.
Корень боли в том, что много лет проектный менеджмент мерил успех формулой «срок–бюджет–объём работ». Если всё уложили — молодцы. Но факт закрытия проекта ещё не значит, что поменялась доля рынка, выросла прибыль или хотя бы стало проще жить клиентам и сотрудникам. Проект может быть формально идеальным и практически бесполезным для бизнеса. Эту трещину между «управлением проектом» и «созданием ценности» PMBOK 8 наконец-то поставил в центр внимания.
Новая редакция уводит фокус от набора процессов и шаблонов к системе создания ценности (value delivery system). Вопрос звучит уже не «как грамотно спланировать и исполнить проект?», а «как через проекты регулярно превращать стратегию компании в реальные результаты?» Это совсем другой уровень ответственности и для компании, и для проектного менеджера.
Что такое ценность в логике PMBOK 8
Чтобы говорить о системе создания ценности, нужно договориться о самом понятии value. PMBOK 8 предлагает смотреть шире привычных «финансовых» метрик и разделять результаты на tangible и intangible. Это, по сути, ответ на вопрос: что именно компания получает на выходе, кроме очередного релиза или внедрённой системы.
Материальный (Tangible) результаты — то, что легко положить в Excel и в отчёт для совета директоров: прибыль, выручка, экономия затрат, рост доли рынка, снижение операционных рисков. Нематериальный (Intangible) — менее очевидные, но часто более долгосрочные эффекты: репутация, лояльность клиентов, узнаваемость бренда, накопленные знания, рост зрелости процессов, устойчивость к кризисам. И именно эти «нематериальные» эффекты часто определяют, будет ли компания зарабатывать через пять лет или останется заложником разовых тактических успехов.
Условно ту же картину можно свернуть в простую таблицу, которой мы часто пользуемся на стартовых сессиях проектов:
| Тип результата | Пример для ИТ-проекта |
|---|---|
| Материальное | Рост EBITDA за счёт автоматизации процесса и снижения затрат на ручной труд |
| Материальное | Увеличение доли онлайн-продаж после запуска нового цифрового канала |
| Нематериальное | Повышение зрелости процессов разработки и сопровождения (меньше хаоса, предсказуемые релизы) |
| Нематериальное | Укрепление бренда работодателя за счёт модернизации технологического стека |
Важно научиться проговаривать оба типа ценности ещё на уровне инициации. Если проект описан только через материальное, велик риск, что он останется «разовым рывком» и не изменит способность организации стабильно создавать результат. Если же есть только красивые нематериальные формулировки без финансовой логики — топ-менеджмент справедливо будет воспринимать инициативу как «игрушку ИТ».
Value Delivery System: как стратегия превращается в проекты
Самое ценное в PMBOK 8 — это взгляд на компанию как на систему, которая непрерывно превращает стратегию в ценность через набор взаимосвязанных элементов. Проект в этой логике — не отправная точка, а инструмент. Если упростить, цепочка выглядит так: Видение → Миссия → Организационная стратегия → Цели → Портфель → Программы & Проекты → Продукты & Операции → Ценность.
На практике мы часто видим обрыв где-то посередине. Есть красивая стратегия на презентациях и есть набор проектов в Jira, но связи между ними почти нет. Команда запускает модный мобильный апи или внедрение новой CRM, потому что «так делают все», а не потому, что это прямой ответ на стратегическую задачу. В системе создания ценности каждый проект должен иметь чёткую «нитку» вверх: к какому стратегическому ориентиру и каким целям он привязан.
Хороший тест: если попросить проектного менеджера за две минуты объяснить, как его проект поддерживает стратегию компании, ответ не должен сводиться к общим словам «повышаем эффективность» и «улучшаем сервис». Внятная связка звучит так: «Наша цель — увеличить долю цифровых продаж с 30% до 50% за два года. Проект по запуску нового мобильного приложения закрывает две ключевые гипотезы в этой стратегии. Мы меряем успех не только релизом, но и долей операций, которые клиенты переводят в мобильный канал за первый год». Это и есть мышление в логике value delivery system, а не просто «сдачи проекта».
Среда проекта: почему контекст важнее методологии
Ещё один важный сдвиг в PMBOK 8 — акцент на среду проекта (project environment). Один и тот же по объёму и даже по составу работ проект будет вести себя по-разному в разных компаниях. На результат влияет всё: внешняя среда, внутренняя культура, регламенты, неформальные практики, распределение власти.
Внешняя среда — это рынок, регуляторика, конкуренты, технологические тренды. Внутренняя — структура компании, стиль управления, уровень доверия между бизнесом и ИТ. Enterprise environmental factors и organizational process assets — те самые «факторы среды» и «организационные активы», которые либо поддерживают ваши проекты, либо создают невидимый встречный ветер. Невозможно всерьёз говорить о ценности проекта, если вы не учитываете, например, что в вашей отрасли через год вступят в силу новые правила, или что внутри компании любые изменения, затрагивающие продажи, требуют длинного цикла согласований.
И здесь важный вывод: адаптировать нужно не только методологию (Agile, каскад, гибрид), но и ожидания от скорости создания ценности. В компании с жёсткой регуляторикой и тяжёлым легаси никакой Agile сам по себе не превратит проект в скоростной катер. Но он может помочь честно показать, где именно «зарыты» тормоза и какие решения нужны на уровне стратегии и портфеля, а не только команды разработки.
Организационная структура и роль PM в разных контекстах
Оргструктура — один из самых недооценённых факторов, который напрямую влияет на то, как именно проект создаёт ценность. PMBOK 8 предлагает смотреть на неё через призму типов: функциональная, матричная (слабая / сбалансированная / сильная), проектно-ориентированная, гибридная, виртуальная. Для практики важно не столько знать определения, сколько честно ответить: «Кто на самом деле принимает решения и у кого есть ресурсы?».
В функциональной структуре центр силы — в линейных руководителях. Проектный менеджер чаще превращается в администратора: координирует встречи, собирает отчёты, но не может самостоятельно перераспределять ресурсы и менять приоритеты. В слабой матрице он уже чуть больше, чем координатор, но по многим вопросам зависит от «родных» начальников сотрудников. В сильной матрице и проектно-ориентированной структуре PM — полноценный управленец: у него есть команда, бюджет и право принимать решения в рамках целей проекта.
Полезно для себя держать в голове простую сравнительную логіку: в функциональной структуре вы создаёте ценность через влияние и переговоры с линейными руководителями, в слабой матрице — через аккуратный баланс интересов, в проектно-ориентированной — через прямое управление ресурсами и рисками. Одна и та же методология в этих трёх мирах даст очень разный эффект. И задача PM — не просто знать, «как правильно по книжке», а трезво оценивать, какую роль он играет в конкретной системе создания ценности.
Роль проектного менеджера в системе создания ценности
На этом фоне сильно меняется и ожидание от проектного менеджера. PMBOK 8 описывает его роль через треугольник: ways of working, power skills, business acumen, в центре которого — результаты (results). Если переводить с «методологического» на человеческий: вам уже недостаточно быть человеком с диаграммой Ганта и хорошим контролем задач. От вас ждут, что вы понимаете, какие подходы к работе уместны (ways of working), умеете работать с людьми и влиянием (power skills) и имеете бизнес хватку (business acumen).
В связке с концепцией value delivery это означает простую вещь: PM становится связующим звеном между стратегией и конкретными решениями в проекте. Он должен уметь задать неудобный вопрос спонсору: «Как именно этот проект поддерживает ваши стратегические цели?», перевести стратегические формулировки в понятные критерии успеха для команды и вовремя поднимать руку, если видит, что проект перестал создавать ценность и просто «крутит педали» ради отчёта. Это уже не про «отчитаться о выполненных задачах», а про разговор на языке результатов и влияния на бизнес.
Как теперь измерять успех проекта
Классная новость для многих PM в том, что PMBOK 8 фактически легализовал то, о чём мы давно говорили в коридорах: успех ≠ объем работы/время/бюджет. Да, треугольник по-прежнему важен — никто не отменял дисциплину управления. Но успех теперь измеряется через созданную ценность и вклад в стратегические цели. Проект, который дал компании конкурентное преимущество и новый поток выручки, но формально вылез за бюджет на 5–10%, в новой логике может быть более успешным, чем идеальный по цифрам, но стратегически пустой.
Отсюда простой вывод: при инициации и закрытии проекта нам нужны другие вопросы. Не только «что мы сделали» и «уложились ли мы в план», а «что изменилось для бизнеса, клиентов, сотрудников», «какие tangible и intangible результаты появились», «как наш проект приблизил компанию к стратегическим целям». И если на эти вопросы нечего ответить, честнее признать, что с точки зрения системы создания ценности проект оказался слабым, даже если все чек-листы формально зелёные.
Практический чек-лист: как внедрять логику Value Delivery
Чтобы не оставаться на уровне красивых концепций, мы обычно предлагаем компаниям начать с небольшого, но честного самоаудита. Ниже — минимальный чек-лист, с которого можно стартовать уже на ближайшем комитете по проектам:
- У каждого ключевого проекта явно прописана связь со стратегическими целями компании (или OKR), и эта связь понятна не только спонсору, но и команде.
- Для проекта определены не только финансовые показатели, но и ожидаемые intangible результаты: изменения в опыте клиента, в зрелости процессов, в знаниях команды.
- Проектный менеджер может в двух-трёх предложениях объяснить, как его проект создаёт ценность и по каким признакам через год можно будет сказать, что она создана.
- Команда понимает контекст: знает ключевые стратегические приоритеты компании и может связать свою работу не только с «текущим спринтом», но и с большой картиной.
- При закрытии проекта команда обсуждает не только то, что получилось или нет, но и то, какую реальную ценность проект создал и где система value delivery дала сбой.
Если по большинству пунктов ответ «нет» или «затрудняюсь» — это не повод отменять все инициативы. Это сигнал, что компания живёт в старой логике «проекты ради проектов». Хорошая новость в том, что переход к логике value delivery не требует мгновенной перестройки всего портфеля. Достаточно начать задавать другие вопросы и на уровне отдельных проектов, и на уровне управления стратегией.
Заключение: от управления проектами к управлению ценностью
PMBOK 8 очень аккуратно, но однозначно сместил фокус: от «как правильно управлять проектом» к «как через проекты системно создавать ценность». Для нас, как для консультантов по ИТ-проектам, это давно назревший шаг. Мир, где достаточно было просто «уложиться в срок и бюджет», закончился. Сегодня компании ожидают от проектов заметного влияния на стратегию, а от PM — роли партнёра в этом влиянии.
Если подвести всё к одной мысли, она будет такой: проект — это временная структура, а ценность — то, что остаётся после него. И чем раньше в компании начинают мыслить в этой логике, тем легче связывать очередную диаграмму Ганта не только с операционными задачами, но и с реальными стратегическими изменениями.
Есть вопросы или мнение по теме?
В нашем Telegram-канале собираются архитекторы, CTO, разработчики и IT-менеджеры. Там можно: задать вопрос авторам разобрать свой кейс обсудить практику внедрения поделиться опытом.
Переходите в Telegram и подключайтесь к профессиональному диалогу!



