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

- Собственники организаций
- Руководители проектных офисов
- Руководители проектов и программ
«Хочу, чтобы нужные проекты запускались и реализовывались как часы, чтобы сроки не сдвигались, чтобы отклонения мы видели не по факту, а заранее, и было сразу понятно, какие меры надо предпринять»
80% наших клиентов именно так представляют себе идеальную картину с проектами в их организации.
Но почему достичь этой идеальной картины так сложно и кто в этом виноват?
Может, неквалифицированные руководители проектов, которые приходят с проблемой на проекте без каких-либо предложений по её устранению? Или же HR-подразделение, которое никак не может наладить систему онбординга, чтобы быстро натаскивать новичков, а не гоняться месяцами за дефицитными ресурсами?
Будем честны – проблема очень часто не только в людях. А в том, что ваша проектная методология просто не работает. Потому что:
- она слишком забюрократизирована и только тормозит проекты;
- она слишком упрощена и не покрывает те аспекты (области внимания), которые должны быть на контроле;
- она не закрывает потребности проектной деятельности в вашей организации: например, не ускоряет процесс онбординга новых РП, когда для вас это критически важно;
- она давно устарела и её невозможно применить к большинству проектов.
Причин, почему методология не работает, может быть много, и то, что описано выше – лишь верхушка айсберга.
Возможно, вы уже пытались её переработать, брали чужую, успешную методологию из другой компании, но она почему-то не прижилась, пытались разработать правила управления проектами собственными силами… но результата ноль. Методология не оказывает никакого положительного эффекта на результаты проектов и вам кажется, что изменить что-либо невозможно.
Чтобы понять, что именно с вашей методологией не так и что нужно изменить, читайте ниже.
Причина 1: отсутствие гибкости в применении методологии
Проектная методология – это ящик с инструментами. Для крупных, сложных и долгосрочных проектов этих инструментов должно быть больше, чем для простых, типовых или коротких. Да и сами эти инструменты будут сложнее.
Например, реестр стейкхолдеров или план коммуникаций будут актуальны для большого, сложного, комплексного проекта с большим количеством заинтересованных сторон. А для небольшого компактного проекта использование данных документов станет лишней тратой времени.
Если вы не применяете методологию гибко, то, очевидно, где-то она будет избыточна и оказывать “тормозящее” влияние на проекты.
Причина 2: отсутствие чёткого понимания, зачем применяется методология
У каждого элемента и инструмента методологии (фаза, этап, роль, документ, совещание и т. д.) должны быть чёткое обоснование и однозначная цель.
Если вы не сформулируете и не донесёте эту цель до того, кто будет использовать инструмент, то вы получите сопротивление.
Обязательно прописывайте цели под использование каждого элемента и инструмента вашей проектной методологии. В этом кейсе по разработке проектной методологии для зрелой ИТ-компании рассказываем о том, как нам удалось внедрить единый стандарт управления в условиях сопротивления ключевых сотрудников.
Причина 3: отсутствие ответов на вопросы «Что?» и «Когда?»
Ответ на вопрос “Что мы делаем?” – это артефакты: документы, промежуточные и конечные результаты, которые возникают в рамках процесса управления или реализации проекта. Также на вопрос “Что мы делаем?” отвечают события (совещания, встречи, церемонии), которые необходимо проводить.
А ответ на вопрос “Когда мы делаем?” даёт понимание, когда (в начале или в конце проекта, конкретного этапа или фазы) и с какой частотой необходимо проводить встречи, мероприятия и другие события, чтобы сохранять управляемость.
Чёткие ответы на вопросы ЧТО и КОГДА дают твёрдую основу для формирования требований к руководителю проекта и другим участникам. Если ответов нет, методология носит формальный характер и её будут игнорировать.
Причина 4: размытые зоны ответственности
Конечно, ответственным за проект является руководитель проекта. Но в принятие решений, подготовку документов вовлечены и другие люди.
Эта ответственность должна быть однозначно определена и закреплена за каждой ролью и должностью. Если этого нет, то невозможно понять, кому поручить ту или иную задачу, а также с кого спросить результат. Это приводит и к несоблюдению методологии, и к бесконечным авралам на проектах.
Причина 5: отсутствие понятной технологии
Всегда можно просто заполнить определённый шаблон, однако часто этого недостаточно. Важны не заполненные клеточки, а ответы на конкретные вопросы. Например, в чём цель проекта, каков его результат?
Очень важно чётко определить и описать технологию заполнения, создания, реализации и т. д. А также то, как осуществить проверку сделанного. Носителем такой технологии могут быть конкретные люди, но эффективнее будет сформировать базу знаний, чтобы хранить в ней соответствующие шаблоны, чек-листы или инструкции. Без всего этого методология рискует стать формальностью.
Причина 6: формальное применение методологии
Часто, после фиксации методологии как документа, она так и остаётся только на бумаге. В реальных проектах она не применяется, её соблюдение не проверяется.
Если методология не применяется или применяется формально – результата от неё ждать не стоит.
Причина 7: отсутствие регулярного аудита
Часто полезность тех или иных инструментов не оценивается. Действительно ли использование методологии помогает снижать риски, а трудоёмкость использования инструмента обоснована?
Иногда от части инструментов можно без потерь отказаться. Что-то можно упростить, а что-то добавить. Именно полезность инструментов вашей методологии определяет её полезность для проектов и организации в целом.
Регулярный аудит необходим, чтобы методология сохраняла свою актуальность.
Подписывайтесь на наш телеграм канал, чтобы быть в курсе современных методов управления проектами и изменениями!


