Риск-менеджмент: твой план A умер в 7:15. Что дальше?
Сегодня мой аккумуляторный триммер совершил героический переход в разряд «исторических артефактов». Ровно за 15 минут до выхода на важную встречу с заказчиком.
Никакого предупреждения. Никаких «низких батарей» или посторонних звуков. Просто щелчок — и ротор встал. В этот момент ты осознаешь разницу между оптимизмом и реальностью. Очень не хочется идти на встречу, когда выбрито пол-лица.
Но, будучи PM, я подсознательно заложил себе подстраховку ещё несколько лет назад. В глубине шкафа пылилась древняя упаковка безопасных бритв, купленная «на всякий случай».
Итог:
— Встреча не сорвана.
— Клиент не увидел «небритого чувака из лесу».
— Триммер уехал в корзину с чувством выполненного долга. Кстати ему исполнилось ровно 2 года.
Короткие выводы для наших рабочих реалий:
1. Реестр рисков должен быть не в только в таблице Excel. Вы обязаны знать хотя бы 3 сценария отказа любого критического элемента. Даже если это просто ваш личный гаджет.
2. План Б не обязан быть изящным. Он обязан быть рабочим. Старая бритва, резервный ноутбук, флешка с презентацией в кармане пиджака — это не архаизм, это ваш «святой Грааль».
3. Кризис наступает в самый неподходящий момент. Не когда у вас есть свободные 2 часа, а когда на счету каждая минута. Если ваш план отказоустойчивости не рассчитан на форс-мажор в 7 утра — это не план, это иллюзия.
И да, сегодня я побрился как мой дед в 80-х — медленно, страшно, но эффективно. Главное — результат, а не инструмент.
Проверьте свои «запасные бритвы» в проектах, пока они ещё лежат на полке.
Ваши риски управляемы? Или вы до сих пор верите, что триммер не сломается?
Напишите в комментариях, с чем вам приходилось сталкиваться на проектах и в быту.
#УправлениеРисками #ProjectManagement #БытоваяАналогия #Антикризис #ПланБ
Сегодня мой аккумуляторный триммер совершил героический переход в разряд «исторических артефактов». Ровно за 15 минут до выхода на важную встречу с заказчиком.
Никакого предупреждения. Никаких «низких батарей» или посторонних звуков. Просто щелчок — и ротор встал. В этот момент ты осознаешь разницу между оптимизмом и реальностью. Очень не хочется идти на встречу, когда выбрито пол-лица.
Но, будучи PM, я подсознательно заложил себе подстраховку ещё несколько лет назад. В глубине шкафа пылилась древняя упаковка безопасных бритв, купленная «на всякий случай».
Итог:
— Встреча не сорвана.
— Клиент не увидел «небритого чувака из лесу».
— Триммер уехал в корзину с чувством выполненного долга. Кстати ему исполнилось ровно 2 года.
Короткие выводы для наших рабочих реалий:
1. Реестр рисков должен быть не в только в таблице Excel. Вы обязаны знать хотя бы 3 сценария отказа любого критического элемента. Даже если это просто ваш личный гаджет.
2. План Б не обязан быть изящным. Он обязан быть рабочим. Старая бритва, резервный ноутбук, флешка с презентацией в кармане пиджака — это не архаизм, это ваш «святой Грааль».
3. Кризис наступает в самый неподходящий момент. Не когда у вас есть свободные 2 часа, а когда на счету каждая минута. Если ваш план отказоустойчивости не рассчитан на форс-мажор в 7 утра — это не план, это иллюзия.
И да, сегодня я побрился как мой дед в 80-х — медленно, страшно, но эффективно. Главное — результат, а не инструмент.
Проверьте свои «запасные бритвы» в проектах, пока они ещё лежат на полке.
Ваши риски управляемы? Или вы до сих пор верите, что триммер не сломается?
Напишите в комментариях, с чем вам приходилось сталкиваться на проектах и в быту.
#УправлениеРисками #ProjectManagement #БытоваяАналогия #Антикризис #ПланБ
Безопасность VBA в MS Project: защита данных и кода
Автоматизация в MS Project через VBA экономит часы работы, но требует осознанного подхода к безопасности. Рассмотрим ключевые риски и способы их минимизации.
Кейс №1: «Случайное удаление»
Планировщик запустил макрос для обновления статусов задач. Из-за отсутствия обработки ошибок и проверки макрос перезаписал даты начала не в той задаче. Результат — потеря данных и ручное восстановление из резервной копии.
Решение: Используйте обработчик ошибок.
Кейс №2: «Несанкционированное изменение»
Разработчик VBA передал коллеге MPP-файл с макросами. Коллега случайно изменил код в одном из модулей, после чего макрос стал работать некорректно, а ошибка проявилась только через месяц.
Решение: Защитите код VBA паролем.
Три базовых правила безопасности работы с VBA обсудим на онлайн-курсе "VBA в Microsoft Project".
Резюме: VBA — мощный инструмент, но его сила требует ответственности. Парольная защита кода, корректная обработка ошибок и осознанные настройки безопасности макросов — минимальный набор, который убережёт ваш проект от потери данных и непредвиденных сбоев.
Автоматизация в MS Project через VBA экономит часы работы, но требует осознанного подхода к безопасности. Рассмотрим ключевые риски и способы их минимизации.
Кейс №1: «Случайное удаление»
Планировщик запустил макрос для обновления статусов задач. Из-за отсутствия обработки ошибок и проверки макрос перезаписал даты начала не в той задаче. Результат — потеря данных и ручное восстановление из резервной копии.
Решение: Используйте обработчик ошибок.
Кейс №2: «Несанкционированное изменение»
Разработчик VBA передал коллеге MPP-файл с макросами. Коллега случайно изменил код в одном из модулей, после чего макрос стал работать некорректно, а ошибка проявилась только через месяц.
Решение: Защитите код VBA паролем.
Три базовых правила безопасности работы с VBA обсудим на онлайн-курсе "VBA в Microsoft Project".
Резюме: VBA — мощный инструмент, но его сила требует ответственности. Парольная защита кода, корректная обработка ошибок и осознанные настройки безопасности макросов — минимальный набор, который убережёт ваш проект от потери данных и непредвиденных сбоев.
8 постов за прошедшую неделю, VBA, ИИ, риски и статистика от PMI.
1. VBA в MS Project автоматизирует до 80% рутины — замена ресурсов, отчёты, календари одной командой.
2. Постановка цели с ИИ устраняет неоднозначности: модель дополняет ограничения, человек принимает финальные решения.
3. Цель проекта — «что сделать», OKR — «как измерить», KPI — мониторинг процесса; ИИ помогает уточнять все три, но не смешивать их.
4. Хаос в коммуникациях — главный тормоз: единая среда, разделение каналов и RACI по потокам информации сокращают переделки на 15–20%.
5. PMI 2026: 81% проектов усложнились, провал сложных — 31% против 13% средних; выход — фокус на системах и согласованности, а не контроле.
6. Штатная замена ресурсов в MS Project ломает пропорции — VBA точечно меняет одного исполнителя, копируя его трудозатраты.
7. Риск-менеджмент: план Б должен быть рабочим, а не изящным — проверьте свои «запасные бритвы» до того, как кризис наступит в 7 утра.
8. Безопасность VBA: защита кода паролем, обработка ошибок и осознанные настройки — минимальный набор против потери данных.
1. VBA в MS Project автоматизирует до 80% рутины — замена ресурсов, отчёты, календари одной командой.
2. Постановка цели с ИИ устраняет неоднозначности: модель дополняет ограничения, человек принимает финальные решения.
3. Цель проекта — «что сделать», OKR — «как измерить», KPI — мониторинг процесса; ИИ помогает уточнять все три, но не смешивать их.
4. Хаос в коммуникациях — главный тормоз: единая среда, разделение каналов и RACI по потокам информации сокращают переделки на 15–20%.
5. PMI 2026: 81% проектов усложнились, провал сложных — 31% против 13% средних; выход — фокус на системах и согласованности, а не контроле.
6. Штатная замена ресурсов в MS Project ломает пропорции — VBA точечно меняет одного исполнителя, копируя его трудозатраты.
7. Риск-менеджмент: план Б должен быть рабочим, а не изящным — проверьте свои «запасные бритвы» до того, как кризис наступит в 7 утра.
8. Безопасность VBA: защита кода паролем, обработка ошибок и осознанные настройки — минимальный набор против потери данных.
❤1
Ваш план управления проектом — это броня или бумага?
Мы все пишем красивые документы. А потом наступает форс-мажор — и оказывается, что бумажный план годится разве что на подставку для кофе.
Давайте без теории. Есть один народный тест на «живучесть» плана:
Если ваш ключевой разработчик заболел, а заказчик не хочет сдвинуть сроки — у вас есть готовый ответ в плане или вы начинаете импровизировать?
А теперь честно: как вы обычно проверяете, что план действительно рабочий?
Может, у вас есть эпичная история, когда план треснул по швам в самый неподходящий момент?
Пишите в комментарии — самые смешные или неожиданные ситуации с планированием. У кого был проект, который шёл строго по плану?
Спойлер: у меня есть «тест плана», но о нём расскажу позже.
Мы все пишем красивые документы. А потом наступает форс-мажор — и оказывается, что бумажный план годится разве что на подставку для кофе.
Давайте без теории. Есть один народный тест на «живучесть» плана:
Если ваш ключевой разработчик заболел, а заказчик не хочет сдвинуть сроки — у вас есть готовый ответ в плане или вы начинаете импровизировать?
А теперь честно: как вы обычно проверяете, что план действительно рабочий?
Может, у вас есть эпичная история, когда план треснул по швам в самый неподходящий момент?
Пишите в комментарии — самые смешные или неожиданные ситуации с планированием. У кого был проект, который шёл строго по плану?
Спойлер: у меня есть «тест плана», но о нём расскажу позже.
Как проверить качество календарного плана проекта
Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология DCMA (Defense Contract Management Agency), включающая 14 точек контроля.
Применение этой методики позволяет снизить количество проблемных мест до единичных случаев.
Критерии DCMA:
1. Логика сети — все задачи должны иметь предшественников/последователей (допустимо не более 5% исключений).
2. Отсутствие опережений — использование опережений (lead) недопустимо, заменяется декомпозицией и связями.
3. Минимизация задержек — не более 5% задач с задержками (lag), без включения резервов.
4. Тип связей — не менее 90% связей типа «Финиш–Старт» (FS).
5. Ограничения задач — не более 5% задач с типом, отличным от «Как можно раньше» (ASAP).
6. Общий резерв — не более 44 рабочих дней (2 мес.) для не более 5% задач.
7. Отрицательный резерв — недопустим.
8. Длительность задачи — не более 44 рабочих дней (требует декомпозиции).
9. Корректность дат — фактические даты не могут быть в будущем.
10. Обеспеченность ресурсами — каждая задача должна иметь назначенный ресурс.
11. Отстающие задачи — не более 5% от базового плана.
12. Тест критического пути — сдвиг критической задачи должен сдвигать срок проекта.
13. Индекс критического пути (CPLI) — целевое значение 1,0, допустимо до 0,95.
14. Индекс выполнения базового плана (BEI) — целевое значение 1,0, допустимо до 0,95.
По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану.
В следующих постах детально обсудим каждый пункт.
Ранее я обещал рассказать про "тест плана", т.е. как проверить качество плана проекта. В проектном управлении качество плана — это не абстракция, а набор измеримых параметров. Один из наиболее практичных подходов — методология DCMA (Defense Contract Management Agency), включающая 14 точек контроля.
Применение этой методики позволяет снизить количество проблемных мест до единичных случаев.
Критерии DCMA:
1. Логика сети — все задачи должны иметь предшественников/последователей (допустимо не более 5% исключений).
2. Отсутствие опережений — использование опережений (lead) недопустимо, заменяется декомпозицией и связями.
3. Минимизация задержек — не более 5% задач с задержками (lag), без включения резервов.
4. Тип связей — не менее 90% связей типа «Финиш–Старт» (FS).
5. Ограничения задач — не более 5% задач с типом, отличным от «Как можно раньше» (ASAP).
6. Общий резерв — не более 44 рабочих дней (2 мес.) для не более 5% задач.
7. Отрицательный резерв — недопустим.
8. Длительность задачи — не более 44 рабочих дней (требует декомпозиции).
9. Корректность дат — фактические даты не могут быть в будущем.
10. Обеспеченность ресурсами — каждая задача должна иметь назначенный ресурс.
11. Отстающие задачи — не более 5% от базового плана.
12. Тест критического пути — сдвиг критической задачи должен сдвигать срок проекта.
13. Индекс критического пути (CPLI) — целевое значение 1,0, допустимо до 0,95.
14. Индекс выполнения базового плана (BEI) — целевое значение 1,0, допустимо до 0,95.
По сути, готовый чек-лист для повышения надёжности плана проекта. Внедрение даже нескольких пунктов (особенно логика сети, типы связей, ограничения и ресурсы) существенно снижает риски срывов и повышает доверие к плану.
В следующих постах детально обсудим каждый пункт.
Критерии DCMA: логика сети
Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1.
1. Логика сети (не более 5% исключений)
Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи.
Почему это важно:
Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования.
Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы.
Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения.
Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).
Методология DCMA (Defense Contract Management Agency) насчитывает 14 контрольных точек. Разберём их детально, начнем с п.1.
1. Логика сети (не более 5% исключений)
Суть: каждая задача должна иметь как минимум одного предшественника и одного последователя (кроме первой и последней). Это требование не бюрократическое, а сущностное. 5% это задачи управленченского характера, например запланированные совещания или встречи.
Почему это важно:
Результат задачи-предшественника является необходимым условием для старта задачи-последователя. Без завершения одного задачи нельзя начинать следующую — это база сетевого планирования.
Если между задачами есть «разрывы» (отсутствие связи), календарный план перестаёт отражать реальную последовательность работ. Расчёт сроков становится нереалистичным: система не понимает, от чего зависит длительность, и не может корректно рассчитать критический путь и резервы.
Отсутствие связей маскирует зависимости, создаёт иллюзию параллельности и закладывает ложные ожидания по срокам завершения.
Практический кейс: в ООО «Аэроэкспресс» этот критерий стал одним из первых в системе автоматизированного контроля. Проверка ведётся через фильтр полей «Предшественники»/«Последователи» — все задачи с пустыми значениями считаются нарушением, кроме осмысленных исключений (например, старт или финиш проекта).
Внедрение ERP проваливается не из-за технологий. Причина — устаревший PMO.
Занимаясь много лет внедрением различных систем класса ERP (Navision, Axapta, Dynamics, 1C), я понял что успех этих проектов зависит в первую очередь от качества управления. В очередной раз это подтверждается исследованием.
Новое исследование Argon & Co (1–2 сентября 2026) делает неудобный вывод: успех внедрения ERP определяется не выбором вендора, а тем, как организовано управление доставкой, принятие решений и координация между командами.
Проблема: традиционные PMO «наблюдают за проблемами, а не решают их». Они полагаются на медленные цепочки эскалации вместо того, чтобы давать командам право действовать. Позволяют вендорам брать фактический контроль над проектом. И не защищают главный дефицитный ресурс — экспертов предметной области, которые разрываются между трансформацией бизнеса и текущими обязанностями.
Результат: 91% бизнес-лидеров не успевают за технологическими изменениями. Компании автоматизируют сломанные процессы вместо того, чтобы их исправлять. Решение: современный PMO должен стать активной функцией доставки, которая: управляет интеграцией и дефицитом экспертов,принимает решения, а не эскалирует их, фокусируется на бизнес-результатах, а не на завершении задач.
Итого: ERP-проект обречён, если ваш PMO всё ещё в эпохе «отчитаться, а не сделать». Трансформация требует другого подхода.
Ссылка на статью:
https://www.consultancy-me.com/news/amp/14297/erp-programs-need-more-than-technology-they-need-a-modern-pmo
#ERP #PMO #ProjectManagement #DigitalTransformation #УправлениеПроектами
Занимаясь много лет внедрением различных систем класса ERP (Navision, Axapta, Dynamics, 1C), я понял что успех этих проектов зависит в первую очередь от качества управления. В очередной раз это подтверждается исследованием.
Новое исследование Argon & Co (1–2 сентября 2026) делает неудобный вывод: успех внедрения ERP определяется не выбором вендора, а тем, как организовано управление доставкой, принятие решений и координация между командами.
Проблема: традиционные PMO «наблюдают за проблемами, а не решают их». Они полагаются на медленные цепочки эскалации вместо того, чтобы давать командам право действовать. Позволяют вендорам брать фактический контроль над проектом. И не защищают главный дефицитный ресурс — экспертов предметной области, которые разрываются между трансформацией бизнеса и текущими обязанностями.
Результат: 91% бизнес-лидеров не успевают за технологическими изменениями. Компании автоматизируют сломанные процессы вместо того, чтобы их исправлять. Решение: современный PMO должен стать активной функцией доставки, которая: управляет интеграцией и дефицитом экспертов,принимает решения, а не эскалирует их, фокусируется на бизнес-результатах, а не на завершении задач.
Итого: ERP-проект обречён, если ваш PMO всё ещё в эпохе «отчитаться, а не сделать». Трансформация требует другого подхода.
Ссылка на статью:
https://www.consultancy-me.com/news/amp/14297/erp-programs-need-more-than-technology-they-need-a-modern-pmo
#ERP #PMO #ProjectManagement #DigitalTransformation #УправлениеПроектами
Consultancy-me.com
ERP programs need more than technology – they need a modern PMO
A new whitepaper from Argon & Co argues that ERP transformation success is determined less by technology choices and more by how organizations govern delivery, manage decision-making, and coordinate
PM перегружены, а важные вопросы тонут в чатах.
Seiko Solutions выпускает AI-платформу TierX, чтобы это исправить.
В системной разработке проекты становятся масштабнее и сложнее. PM требуется принимать всё более быстрые и точные решения. Проблема в том, что критические сигналы — задержки в выполнении задач, расхождения в ожиданиях стейкхолдеров, другие тревожные моменты — не фиксируются в официальных отчётах. Они разбросаны по чатам, встречам и мелким несоответствиям в данных.
Сейчас опытные PM тратят силы на то, чтобы вручную собирать эти фрагменты в единую картину. Нагрузка растёт, растут и риски.
Как работает TierX:
Платформа на базе ИИ и AI-агентов непрерывно анализирует разрозненную информацию, понимает контекст всего проекта и предлагает PM информацию, необходимую для принятия решений. AI структурирует вопросы, расставляет приоритеты, выявляет риски и помогает прорабатывать варианты реагирования.
Экспертные знания опытных PM и технических специалистов накапливаются в системе и превращаются в интеллектуальные активы, доступные всей организации.
Ключевая философия: AI не заменяет человека, а позволяет ему сосредоточиться на главном — «диалоге, суждениях и принятии решений».
Статус: с сентября 2026 стартует бета-тестирование и PoC с корпоративными клиентами (совместно с Time Creators, имеющей богатый опыт в управлении проектами по разработке систем и внедрению ERP). Выход на рынок запланирован до конца года.
Подробнее здесь (правда на японском):
https://cloud.watch.impress.co.jp/docs/news/2137714.html
#ProjectManagement #AI #TierX #SeikoSolutions #PMO #DigitalTransformation #УправлениеПроектами
Seiko Solutions выпускает AI-платформу TierX, чтобы это исправить.
В системной разработке проекты становятся масштабнее и сложнее. PM требуется принимать всё более быстрые и точные решения. Проблема в том, что критические сигналы — задержки в выполнении задач, расхождения в ожиданиях стейкхолдеров, другие тревожные моменты — не фиксируются в официальных отчётах. Они разбросаны по чатам, встречам и мелким несоответствиям в данных.
Сейчас опытные PM тратят силы на то, чтобы вручную собирать эти фрагменты в единую картину. Нагрузка растёт, растут и риски.
Как работает TierX:
Платформа на базе ИИ и AI-агентов непрерывно анализирует разрозненную информацию, понимает контекст всего проекта и предлагает PM информацию, необходимую для принятия решений. AI структурирует вопросы, расставляет приоритеты, выявляет риски и помогает прорабатывать варианты реагирования.
Экспертные знания опытных PM и технических специалистов накапливаются в системе и превращаются в интеллектуальные активы, доступные всей организации.
Ключевая философия: AI не заменяет человека, а позволяет ему сосредоточиться на главном — «диалоге, суждениях и принятии решений».
Статус: с сентября 2026 стартует бета-тестирование и PoC с корпоративными клиентами (совместно с Time Creators, имеющей богатый опыт в управлении проектами по разработке систем и внедрению ERP). Выход на рынок запланирован до конца года.
Подробнее здесь (правда на японском):
https://cloud.watch.impress.co.jp/docs/news/2137714.html
#ProjectManagement #AI #TierX #SeikoSolutions #PMO #DigitalTransformation #УправлениеПроектами
PM Symposium 2026 в Японии: PM-форум о том, как ИИ меняет управление проектами
3–4 сентября в Токио прошёл PM Symposium 2026 — крупнейший в Японии форум по проектному управлению, организованный Японской ассоциацией проектного менеджмента (PMAJ) при поддержке Министерства экономики, торговли и промышленности.
Главная тема: «Программный и проектный менеджмент в эпоху AI».
Ключевой вопрос форума — в эпоху AI-агентов как меняется роль проектного менеджера? Как сохранить человеческое лидерство и создавать ценность, когда машины берут на себя всё больше функций?
Организаторы подчеркнули: управление проектами трансформируется — от решения задач к созданию бизнес-ценности: цифровая трансформация, новые бизнес-модели, скорость реагирования на изменения.
С докладами выступили представители Denso, JGC Holdings, Fujitsu, Национальной астрономической обсерватории Японии.
Главный вывод форума: как отметила руководитель программы Исикава Хироко, «в этом году мы подготовили программу, которую можно назвать кульминацией всего, что мы делали с 2023 года в области AI». Форум подтвердил: AI не заменяет проектных менеджеров, но меняет их работу. Ключевой вопрос — не «как внедрить AI», а «как сохранить человеческое лидерство в эпоху AI».
https://www.pmaj.or.jp/online/2606/relay_2.html
#PMAJ #PMSymposium2026 #ProjectManagement #AI #PMO #УправлениеПроектами
3–4 сентября в Токио прошёл PM Symposium 2026 — крупнейший в Японии форум по проектному управлению, организованный Японской ассоциацией проектного менеджмента (PMAJ) при поддержке Министерства экономики, торговли и промышленности.
Главная тема: «Программный и проектный менеджмент в эпоху AI».
Ключевой вопрос форума — в эпоху AI-агентов как меняется роль проектного менеджера? Как сохранить человеческое лидерство и создавать ценность, когда машины берут на себя всё больше функций?
Организаторы подчеркнули: управление проектами трансформируется — от решения задач к созданию бизнес-ценности: цифровая трансформация, новые бизнес-модели, скорость реагирования на изменения.
С докладами выступили представители Denso, JGC Holdings, Fujitsu, Национальной астрономической обсерватории Японии.
Главный вывод форума: как отметила руководитель программы Исикава Хироко, «в этом году мы подготовили программу, которую можно назвать кульминацией всего, что мы делали с 2023 года в области AI». Форум подтвердил: AI не заменяет проектных менеджеров, но меняет их работу. Ключевой вопрос — не «как внедрить AI», а «как сохранить человеческое лидерство в эпоху AI».
https://www.pmaj.or.jp/online/2606/relay_2.html
#PMAJ #PMSymposium2026 #ProjectManagement #AI #PMO #УправлениеПроектами