Спасение утопающих дело рук самих утопающих.
Продолжение.
Выявить проблему — половина дела. Вторая половина — исправить ситуацию. Какие варианты:
1. Исправляем и продолжаем. Наиболее частый сценарий. ИИ помогает определить, какие именно факторы создают убыток: завышенные длительности, неверная логика связей, нереалистичные допущения в оценке. Затем — точечная корректировка: пересмотр объёма, перераспределение ресурсов, замена исполнителей на критическом пути.
2. Сокращаем объём, сохраняя срок. Если бюджет уже исчерпан, а результат нужен вовремя — уменьшаем scope. ИИ показывает, какие задачи можно отложить без критического ущерба для бизнес-ценности.
3. Пересматриваем сроки. Иногда честнее сдвинуть дату, чем героически сжигать оставшийся бюджет. ИИ помогает оценить, какой сдвиг минимально необходим и какие последствия это создаст для зависимых проектов.
4. Признаём поражение. Самый болезненный, но иногда единственно верный вариант. Если ИИ показывает устойчивый тренд к минусовой марже на протяжении нескольких месяцев, а вариантов исправления нет — остановка проекта становится решением, которое сохраняет деньги для более перспективных инициатив. Политика, sunk-cost bias* и «мы уже столько вложили» — это не то, про что в этой ситуации недо думать.
Убыточные проекты не исчезнут. Но с ИИ у вас появляется шанс узнать о них не на этапе закрытия, а на этапе, когда ещё можно что-то изменить.
*Sunk-cost bias (ошибка невозвратных затрат) — это когда мы продолжаем вкладывать время, деньги или силы во что-то только потому, что уже много вложили, хотя дальнейшие вложения не имеют смысла.
#ProjectManagement #AI #PMO #RiskManagement #УправлениеПроектами
Продолжение.
Выявить проблему — половина дела. Вторая половина — исправить ситуацию. Какие варианты:
1. Исправляем и продолжаем. Наиболее частый сценарий. ИИ помогает определить, какие именно факторы создают убыток: завышенные длительности, неверная логика связей, нереалистичные допущения в оценке. Затем — точечная корректировка: пересмотр объёма, перераспределение ресурсов, замена исполнителей на критическом пути.
2. Сокращаем объём, сохраняя срок. Если бюджет уже исчерпан, а результат нужен вовремя — уменьшаем scope. ИИ показывает, какие задачи можно отложить без критического ущерба для бизнес-ценности.
3. Пересматриваем сроки. Иногда честнее сдвинуть дату, чем героически сжигать оставшийся бюджет. ИИ помогает оценить, какой сдвиг минимально необходим и какие последствия это создаст для зависимых проектов.
4. Признаём поражение. Самый болезненный, но иногда единственно верный вариант. Если ИИ показывает устойчивый тренд к минусовой марже на протяжении нескольких месяцев, а вариантов исправления нет — остановка проекта становится решением, которое сохраняет деньги для более перспективных инициатив. Политика, sunk-cost bias* и «мы уже столько вложили» — это не то, про что в этой ситуации недо думать.
Убыточные проекты не исчезнут. Но с ИИ у вас появляется шанс узнать о них не на этапе закрытия, а на этапе, когда ещё можно что-то изменить.
*Sunk-cost bias (ошибка невозвратных затрат) — это когда мы продолжаем вкладывать время, деньги или силы во что-то только потому, что уже много вложили, хотя дальнейшие вложения не имеют смысла.
#ProjectManagement #AI #PMO #RiskManagement #УправлениеПроектами
PMI обновила экзамен PMP: акцент на ИИ и стратегические решения
PMI обновила сертификационный экзамен PMP, чтобы отразить меняющиеся навыки, которые требуют работодатели в условиях трансформации рабочих мест под влиянием ИИ. Теперь недостаточно просто «управлять проектом» — нужно ещё и бизнес спасать. Раньше проверялось умеет ли кандидат в PMP вести проект. Теперь проверяется, умеет ли он вовремя сказать «стоп» и объяснить, почему это было стратегически верное решение.
Что изменилось:
- Business Environment вырос с 8% до 26% экзамена.
- Время экзамена увеличено до 240 минут.
- Появился кейс-раздел в начале экзамена.
- Усилен акцент на выравнивании с бизнесом, стратегическом принятии решений, вовлечении стейкхолдеров, лидерстве, устойчивости и доставке проектов в AI-средах.
ИИ — теперь не теория, а сценарии. Вас не спросят, что такое машинное обучение. Спросят: «ИИ-система предложила перераспределить ресурсы, но вы видите риск для стейкхолдеров — что делать?» Спойлер: ответ не «следовать рекомендации ИИ».
По данным PMI, количество выданных сертификатов PMP выросло на 36% год к году за первые пять месяцев 2026 года.
https://www.pmi.org/es-es/lim/sitecore/content/pmiheadless/home/certifications/project-management-pmp/new-exam
#PMP #PMI #ProjectManagement #AI #PMO #Сертификация
PMI обновила сертификационный экзамен PMP, чтобы отразить меняющиеся навыки, которые требуют работодатели в условиях трансформации рабочих мест под влиянием ИИ. Теперь недостаточно просто «управлять проектом» — нужно ещё и бизнес спасать. Раньше проверялось умеет ли кандидат в PMP вести проект. Теперь проверяется, умеет ли он вовремя сказать «стоп» и объяснить, почему это было стратегически верное решение.
Что изменилось:
- Business Environment вырос с 8% до 26% экзамена.
- Время экзамена увеличено до 240 минут.
- Появился кейс-раздел в начале экзамена.
- Усилен акцент на выравнивании с бизнесом, стратегическом принятии решений, вовлечении стейкхолдеров, лидерстве, устойчивости и доставке проектов в AI-средах.
ИИ — теперь не теория, а сценарии. Вас не спросят, что такое машинное обучение. Спросят: «ИИ-система предложила перераспределить ресурсы, но вы видите риск для стейкхолдеров — что делать?» Спойлер: ответ не «следовать рекомендации ИИ».
По данным PMI, количество выданных сертификатов PMP выросло на 36% год к году за первые пять месяцев 2026 года.
https://www.pmi.org/es-es/lim/sitecore/content/pmiheadless/home/certifications/project-management-pmp/new-exam
#PMP #PMI #ProjectManagement #AI #PMO #Сертификация
Использование ИИ в проектах само по себе не является преимуществом.
Tempo Software опубликовала отчёт «2026 State of AI in Portfolio Management». Что интересного в этом отчете?
Из тех компаний, что используют ИИ, только 33% делегируют агентам реальную работу: код, документацию, QA. Остальные 58% используют ИИ для... отчётов. 47% для дашбордов. 26% для приоритизации. 20% для сценарного планирования.
То есть ИИ в большинстве компаний это не работник. Это красивый отчёт о работе. Который, кстати, 46% команд дублируют вручную. Потому что не доверяют. Или не понимают, что делать с результатом.
42% руководителей не могут связать затраты на ИИ с ROI. 39% не могут отличить работу ИИ от работы человека в своих текущих инструментах. 55% команд, активно использующих ИИ, не могут атрибутировать результат, где вклад агента, а где человека.
Но вот что интересно. У организаций с ИИ агентами 71% проектов завершаются в срок. Без агентов только 55%.
83% руководителей хотят, чтобы платформа рекомендовала, как исправить стратегические ошибки. А не просто сигнализировала о проблемах.
#ProjectManagement #AI #PMO #TempoSoftware #PortfolioManagement #AIagents
Tempo Software опубликовала отчёт «2026 State of AI in Portfolio Management». Что интересного в этом отчете?
Из тех компаний, что используют ИИ, только 33% делегируют агентам реальную работу: код, документацию, QA. Остальные 58% используют ИИ для... отчётов. 47% для дашбордов. 26% для приоритизации. 20% для сценарного планирования.
То есть ИИ в большинстве компаний это не работник. Это красивый отчёт о работе. Который, кстати, 46% команд дублируют вручную. Потому что не доверяют. Или не понимают, что делать с результатом.
42% руководителей не могут связать затраты на ИИ с ROI. 39% не могут отличить работу ИИ от работы человека в своих текущих инструментах. 55% команд, активно использующих ИИ, не могут атрибутировать результат, где вклад агента, а где человека.
Но вот что интересно. У организаций с ИИ агентами 71% проектов завершаются в срок. Без агентов только 55%.
«Использование ИИ само по себе не является преимуществом. Важно то, могут ли организации заставить агентов работать и управлять этой работой вместе с людьми, инвестициями и стратегическими приоритетами» - CEO Tempo Software.
83% руководителей хотят, чтобы платформа рекомендовала, как исправить стратегические ошибки. А не просто сигнализировала о проблемах.
#ProjectManagement #AI #PMO #TempoSoftware #PortfolioManagement #AIagents
👍3
Критерий DCMA №8
Длительность задачи — не более 44 рабочих дней.
Продолжаем разбор методики DCMA.
Восьмой пункт устанавливает: длительность задачи не должна превышать 44 рабочих дней (около 2 месяцев). Задачи большей длительности требуют декомпозиции.
Почему это критично:
Длительная задача скрывает реальный прогресс, контроль такой задачи становится малоэффективным. DCMA прямо указывает: длинные задачи скрывают детали реальной работы. Аналогичный подход описан в документации Microsoft по работе с длительностью задач.
Кроме того, длительные задачи искажают расчёт критического пути и резервов. Система не может корректно оценить, где именно возникает отклонение, пока задача не завершится.
Как проверять в MS Project с помощью VBA:
Вместо ручного просмотра сотен строк плана можно написать макрос, который автоматически выявит задачи с длительностью более 44 рабочих дней и пометит их для декомпозиции.
Код проходит по всем задачам активного проекта, сравнивает длительность с порогом (44 рабочих дня) и помечает нарушителей в текстовом поле для последующего анализа.
Можно заменить код установкой соответствующего фильтра, но если вы проверяете другие критерии DCMA, то вам придется ставить как минимум 14 разных фильтров.
Практический результат:
Внедрение такой проверки в регламент контроля качества планов позволяет:
- Автоматически выявлять задачи, требующие декомпозиции, до утверждения базового плана.
- Снижать риски срыва сроков за счёт более детального контроля.
- Формировать отчётность по критерию DCMA №8 без ручного труда.
44 дня — разумный порог. Если задача длится дольше, её нужно разбить на подзадачи. А VBA в MS Project делает эту проверку рутинной и безошибочной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Длительность задачи — не более 44 рабочих дней.
Продолжаем разбор методики DCMA.
Восьмой пункт устанавливает: длительность задачи не должна превышать 44 рабочих дней (около 2 месяцев). Задачи большей длительности требуют декомпозиции.
Почему это критично:
Длительная задача скрывает реальный прогресс, контроль такой задачи становится малоэффективным. DCMA прямо указывает: длинные задачи скрывают детали реальной работы. Аналогичный подход описан в документации Microsoft по работе с длительностью задач.
Кроме того, длительные задачи искажают расчёт критического пути и резервов. Система не может корректно оценить, где именно возникает отклонение, пока задача не завершится.
Как проверять в MS Project с помощью VBA:
Вместо ручного просмотра сотен строк плана можно написать макрос, который автоматически выявит задачи с длительностью более 44 рабочих дней и пометит их для декомпозиции.
Код проходит по всем задачам активного проекта, сравнивает длительность с порогом (44 рабочих дня) и помечает нарушителей в текстовом поле для последующего анализа.
Можно заменить код установкой соответствующего фильтра, но если вы проверяете другие критерии DCMA, то вам придется ставить как минимум 14 разных фильтров.
Практический результат:
Внедрение такой проверки в регламент контроля качества планов позволяет:
- Автоматически выявлять задачи, требующие декомпозиции, до утверждения базового плана.
- Снижать риски срыва сроков за счёт более детального контроля.
- Формировать отчётность по критерию DCMA №8 без ручного труда.
44 дня — разумный порог. Если задача длится дольше, её нужно разбить на подзадачи. А VBA в MS Project делает эту проверку рутинной и безошибочной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Atlassian решила: пусть агенты работают
Atlassian анонсировала новые возможности в Jira и DX для управления агентной разработкой. И вот главная цифра: 94% инженерных руководителей используют ИИ, но только 6% имеют системы, чтобы масштабировать его на весь жизненный цикл разработки.
Что теперь умеет Jira:
- Code Context. Агенты получают доступ к знаниям о многопозиционных кодовых базах через Teamwork Graph.
- Agent Context Controls. Платформенные команды решают, к каким пространствам Jira и Confluence агенты имеют доступ.
- Agent loops in Jira. Агенты сканируют бэклог, берут нераспределённые задачи, генерируют код и создают pull-запросы прямо в Jira.
- DX for Agentic Development. Измеряет влияние ИИ на пропускную способность, качество, адоптацию и стоимость.
64% прирост производительности получили команды, чьи ИИ-инструменты использовали больше контекста Atlassian. То есть если дать агенту правильный контекст — он работает. Не дать — получаете код, который «вроде работает, но не так».
https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows
#Atlassian #Jira #AI #AgenticEngineering #ProjectManagement #PMO
Atlassian анонсировала новые возможности в Jira и DX для управления агентной разработкой. И вот главная цифра: 94% инженерных руководителей используют ИИ, но только 6% имеют системы, чтобы масштабировать его на весь жизненный цикл разработки.
Что теперь умеет Jira:
- Code Context. Агенты получают доступ к знаниям о многопозиционных кодовых базах через Teamwork Graph.
- Agent Context Controls. Платформенные команды решают, к каким пространствам Jira и Confluence агенты имеют доступ.
- Agent loops in Jira. Агенты сканируют бэклог, берут нераспределённые задачи, генерируют код и создают pull-запросы прямо в Jira.
- DX for Agentic Development. Измеряет влияние ИИ на пропускную способность, качество, адоптацию и стоимость.
64% прирост производительности получили команды, чьи ИИ-инструменты использовали больше контекста Atlassian. То есть если дать агенту правильный контекст — он работает. Не дать — получаете код, который «вроде работает, но не так».
https://www.itpro.com/software/development/atlassian-introduces-always-on-capabilities-for-agentic-development-workflows
Atlassian — австралийская компания-разработчик программного обеспечения для командной работы и управления проектами, основанная в 2002 году в Сиднее Майком Кэннон-Бруксом и Скоттом Фаркуаром. Её флагманские продукты — трекер задач Jira и корпоративная вики Confluence — используются более чем 20 000 организаций по всему миру, включая Microsoft, Oracle, Amazon и NASA. Штаб-квартира компании находится в Сан-Франциско, а сама она является публичной (NASDAQ: TEAM) с рыночной капитализацией около $42,5 млрд.
#Atlassian #Jira #AI #AgenticEngineering #ProjectManagement #PMO
Критерий DCMA №9:
Некорректные даты — недопустимы.
Продолжаем разбор методики DCMA. Девятый пункт устанавливает: в плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате.
Что это значит: если сегодня 16 сентября, а в плане у задачи стоит фактическое начало 20 сентября — это ошибка. Факт — это то, что уже произошло. Будущее может быть только планом, но не фактом.
Почему это важно:
- Некорректные даты искажают реальную картину проекта. Руководитель видит «факт», которого ещё не было, и принимает решения на основе недостоверных данных.
- Это сигнал о некачественном обновлении плана: либо даты проставлены «на автомате», либо план не синхронизирован с реальностью.
- Критерий напрямую связан с достоверностью отчётности. Если факт в будущем — отчёт не отражает реальное состояние проекта.
Как проверять в MS Project с помощью VBA:
Можно сделать ручную проверку путем установки фильтра. Но удобнее при помощи VBA, в нем можно закодировать проверку сразу 14 критериев. Макрос перебирает все задачи активного проекта, сравнивает поля «Фактическое начало» и «Фактическое окончание» с текущей датой и помечает нарушителей в текстовых полях (например, Text1 и Text2). Дальше достаточно поставить фильтр по этим полям — и все проблемные строки перед вами. Такую проверку можно запускать перед каждым формированием отчётности.
Внедрение такой проверки в регламент контроля качества планов позволяет:
· Автоматически выявлять задачи с некорректными фактическими датами до формирования отчётности.
· Снижать риски принятия решений на основе недостоверных данных.
Факт в будущем — это не «почти сделано». Это ошибка в данных. А VBA в MS Project делает проверку быстрой и регулярной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Некорректные даты — недопустимы.
Продолжаем разбор методики DCMA. Девятый пункт устанавливает: в плане не должно быть задач, у которых фактическое начало или фактическое завершение заданы в будущем по отношению к текущей дате.
Что это значит: если сегодня 16 сентября, а в плане у задачи стоит фактическое начало 20 сентября — это ошибка. Факт — это то, что уже произошло. Будущее может быть только планом, но не фактом.
Почему это важно:
- Некорректные даты искажают реальную картину проекта. Руководитель видит «факт», которого ещё не было, и принимает решения на основе недостоверных данных.
- Это сигнал о некачественном обновлении плана: либо даты проставлены «на автомате», либо план не синхронизирован с реальностью.
- Критерий напрямую связан с достоверностью отчётности. Если факт в будущем — отчёт не отражает реальное состояние проекта.
Как проверять в MS Project с помощью VBA:
Можно сделать ручную проверку путем установки фильтра. Но удобнее при помощи VBA, в нем можно закодировать проверку сразу 14 критериев. Макрос перебирает все задачи активного проекта, сравнивает поля «Фактическое начало» и «Фактическое окончание» с текущей датой и помечает нарушителей в текстовых полях (например, Text1 и Text2). Дальше достаточно поставить фильтр по этим полям — и все проблемные строки перед вами. Такую проверку можно запускать перед каждым формированием отчётности.
Внедрение такой проверки в регламент контроля качества планов позволяет:
· Автоматически выявлять задачи с некорректными фактическими датами до формирования отчётности.
· Снижать риски принятия решений на основе недостоверных данных.
Факт в будущем — это не «почти сделано». Это ошибка в данных. А VBA в MS Project делает проверку быстрой и регулярной.
#DCMA #ProjectManagement #Scheduling #MSProject #VBA #PMO #УправлениеПроектами
Не так страшны первые девяносто процентов выполнения задачи, как вторые
Прошла неделя работы над задачей. Руководитель подходит к сотруднику:
— Как дела? Сколько процентов готово?
— Ну... процентов семьдесят.
— Семьдесят? Отлично! Значит, к пятнице закончим?
— Ну... наверное. Там ещё пара доработок и что-то по мелочи.
Через неделю выясняется, что «семьдесят процентов» были субъективной оценкой настроения, а не состояния задачи. И что «мелочь» — это в лучшем случае половина оставшегося объёма.
Классика жанра.
Процент выполнения — это часто не информация, а художественный жанр. Трёхдневная задача, идёт второй день, готово на 50%? Звучит убедительно. Пока не спросишь: «Сколько времени нужно, чтобы закончить?»
Правильный вопрос менеджера — не «сколько сделано», а «сколько осталось». И не в процентах, а в днях. Всё остальное — либо отчётность, либо самоуспокоение.
Лучше если есть возможность объективно оценивать состояние задачи. Об этом в следующих постах.
#УправлениеПроектами #PMO #КонтрольПроектов
Прошла неделя работы над задачей. Руководитель подходит к сотруднику:
— Как дела? Сколько процентов готово?
— Ну... процентов семьдесят.
— Семьдесят? Отлично! Значит, к пятнице закончим?
— Ну... наверное. Там ещё пара доработок и что-то по мелочи.
Через неделю выясняется, что «семьдесят процентов» были субъективной оценкой настроения, а не состояния задачи. И что «мелочь» — это в лучшем случае половина оставшегося объёма.
Классика жанра.
Процент выполнения — это часто не информация, а художественный жанр. Трёхдневная задача, идёт второй день, готово на 50%? Звучит убедительно. Пока не спросишь: «Сколько времени нужно, чтобы закончить?»
Правильный вопрос менеджера — не «сколько сделано», а «сколько осталось». И не в процентах, а в днях. Всё остальное — либо отчётность, либо самоуспокоение.
Лучше если есть возможность объективно оценивать состояние задачи. Об этом в следующих постах.
#УправлениеПроектами #PMO #КонтрольПроектов
Критерий DCMA №10: Ресурсы
Каждая задача должна быть обеспечена необходимыми ресурсами
Продолжаем разбор методики DCMA. Десятый пункт устанавливает: все задачи проекта (кроме вех, суммарных задач и работ типа LOE*) должны иметь назначенные ресурсы или стоимость. Если задача есть, а исполнителя нет — это не план, а «набросок» работ.
Почему это критично:
- Без ресурсов нельзя корректно оценить продолжительность. Разные ресурсы – разная производительность. Разная производительность – разная продолжительность.
- Риск перегрузки команд и оборудования. Непонятно кто загружен, а кто простаивает.
- Бюджет, трудозатраты и прогресс становятся недостоверными. План без ресурсов — это чертёж без материалов: выглядит красиво, но построить нельзя.
Целевое значение:
В отличие от других критериев DCMA, здесь нет порога «5%». Для качественного плана значение должно быть 0% — все задачи обеспечены.
Как проверять в MS Project:
В MS Project назначение ресурсов или затрат отображается в представлении «Использование задач» (Task Usage) и в столбцах «Названия ресурсов» / «Затраты». Для быстрой проверки используется фильтр по задачам с пустыми значениями в этих полях.
Если в плане есть задачи без ресурсов — это сигнал: план надо дорабатывать.
#DCMA #ProjectManagement #Scheduling #MSProject #PMO #УправлениеПроектами
Каждая задача должна быть обеспечена необходимыми ресурсами
Продолжаем разбор методики DCMA. Десятый пункт устанавливает: все задачи проекта (кроме вех, суммарных задач и работ типа LOE*) должны иметь назначенные ресурсы или стоимость. Если задача есть, а исполнителя нет — это не план, а «набросок» работ.
Почему это критично:
- Без ресурсов нельзя корректно оценить продолжительность. Разные ресурсы – разная производительность. Разная производительность – разная продолжительность.
- Риск перегрузки команд и оборудования. Непонятно кто загружен, а кто простаивает.
- Бюджет, трудозатраты и прогресс становятся недостоверными. План без ресурсов — это чертёж без материалов: выглядит красиво, но построить нельзя.
Целевое значение:
В отличие от других критериев DCMA, здесь нет порога «5%». Для качественного плана значение должно быть 0% — все задачи обеспечены.
Как проверять в MS Project:
В MS Project назначение ресурсов или затрат отображается в представлении «Использование задач» (Task Usage) и в столбцах «Названия ресурсов» / «Затраты». Для быстрой проверки используется фильтр по задачам с пустыми значениями в этих полях.
Если в плане есть задачи без ресурсов — это сигнал: план надо дорабатывать.
.
Level of Effort (LOE) — это «поддерживающая» задача.
Она не создаёт конкретный продукт, а обеспечивает работу других задач.
Длится ровно столько, сколько длится то, что она поддерживает
#DCMA #ProjectManagement #Scheduling #MSProject #PMO #УправлениеПроектами