+7 (926) 827 3222
17 окт 2024

Семь причин, почему ваша проектная методология не работает

Для кого:
  • Собственники организаций
  • Руководители проектных офисов
  • Руководители проектов и программ

«Хочу, чтобы нужные проекты запускались и реализовывались как часы, чтобы сроки не сдвигались, чтобы отклонения мы видели не по факту, а заранее, и было сразу понятно, какие меры надо предпринять»

80% наших клиентов именно так представляют себе идеальную картину с проектами в их организации.

Но почему достичь этой идеальной картины так сложно и кто в этом виноват? 

Может, неквалифицированные руководители проектов, которые приходят с проблемой на проекте без каких-либо предложений по её устранению? Или же HR-подразделение, которое никак не может наладить систему онбординга, чтобы быстро натаскивать новичков, а не гоняться месяцами за дефицитными ресурсами?

Будем честны – проблема очень часто не только в людях. А в том, что ваша проектная методология просто не работает. Потому что:

  • она слишком забюрократизирована и только тормозит проекты;
  • она слишком упрощена и не покрывает те аспекты (области внимания), которые должны быть на контроле;
  • она не закрывает потребности проектной деятельности в вашей организации: например, не ускоряет процесс онбординга новых РП, когда для вас это критически важно;
  • она давно устарела и её невозможно применить к большинству проектов.

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

Возможно, вы уже пытались её переработать, брали чужую, успешную методологию из другой компании, но она почему-то не прижилась, пытались разработать правила управления проектами собственными силами… но результата ноль. Методология не оказывает никакого положительного эффекта на результаты проектов и вам кажется, что изменить что-либо невозможно.

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

Причина 1: отсутствие гибкости в применении методологии

Проектная методология – это ящик с инструментами. Для крупных, сложных и долгосрочных проектов этих инструментов должно быть больше, чем для простых, типовых или коротких. Да и сами эти инструменты будут сложнее.

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

Если вы не применяете методологию гибко, то, очевидно, где-то она будет избыточна и оказывать “тормозящее” влияние на проекты. 

Причина 2: отсутствие чёткого понимания, зачем применяется методология

У каждого элемента и инструмента методологии (фаза, этап, роль, документ, совещание и т. д.) должны быть чёткое обоснование и однозначная цель.

Если вы не сформулируете и не донесёте эту цель до того, кто будет использовать инструмент, то вы получите сопротивление.

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

Причина 3: отсутствие ответов на вопросы «Что?» и «Когда?»

Ответ на вопрос “Что мы делаем?” – это артефакты: документы, промежуточные и конечные результаты, которые возникают в рамках процесса управления или реализации проекта. Также на вопрос “Что мы делаем?” отвечают события (совещания, встречи, церемонии), которые необходимо проводить.

А ответ на вопрос “Когда мы делаем?” даёт понимание, когда (в начале или в конце проекта, конкретного этапа или фазы) и с какой частотой необходимо проводить встречи, мероприятия и другие события, чтобы сохранять управляемость.

Чёткие ответы на вопросы ЧТО и КОГДА дают твёрдую основу для формирования требований к руководителю проекта и другим участникам. Если ответов нет, методология носит формальный характер и её будут игнорировать.

Причина 4: размытые зоны ответственности

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

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

Причина 5: отсутствие понятной технологии

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

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

Причина 6: формальное применение методологии

Часто, после фиксации методологии как документа, она так и остаётся только на бумаге. В реальных проектах она не применяется, её соблюдение не проверяется.

Если методология не применяется или применяется формально – результата от неё ждать не стоит.

Причина 7: отсутствие регулярного аудита

Часто полезность тех или иных инструментов не оценивается. Действительно ли использование методологии помогает снижать риски, а трудоёмкость использования инструмента обоснована?

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

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

Подписывайтесь на наш телеграм канал, чтобы быть в курсе современных методов управления проектами и изменениями!

Авторы статьи:
Андрей Малахов
Прокомментировать статью
Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

Комментарий успешно отправлен

Произошла ошибка при отправке. Попробуйте еще раз

Подписаться на рассылку
Высылаем анонсы статей и полезные материалы

Нажимая на кнопку "Подписаться", вы соглашаетесь с политикой конфиденциальности

Смотрите также:
28 Ноя 2024
Что такое Аджайл? Принципы и ценности
В этой статье рассмотрим ценности и принципы гибкой методологии и как они интегрированы в работу проектной команды.
28 Ноя 2024
Scrum vs Kanban: в чем разница и что выбрать?
Scrum и Kanban — это два популярных подхода к управлению проектами в Agile-среде, каждый из которых имеет особенности и преимущества. Читайте о ключевых отличиях этих подходов в нашей статье.
28 Ноя 2024
Agile vs Scrum: в чём разница
В мире управления проектами часто встречаются термины «Agile» и «Scrum». Эти подходы направлены на повышение гибкости и прозрачности процессов, что помогает командам достигать целей. В этой статье рассмотрим отличия в этих подходах.
Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена