Представьте, что вы управляете портфелем ценных бумаг, не видя котировок, или портфелем недвижимости, не зная, какие объекты сданы, а какие простаивают. Звучит абсурдно, но именно так многие руководители обращаются с портфелем проектов, хотя это тоже инвестиции – в автоматизацию, модернизацию, организационные изменения. Причем речь может идти о сотнях миллионов рублей. За биржевым портфелем следят ежедневно, а состояние проектов выясняют раз в квартал – часто вместе с неприятными сюрпризами. По данным Project Management Institute, 47% проектов выбиваются из графика, а 43% превышают бюджет. Причины отклонений могут быть разными, но многие риски возникают именно на уровне портфеля: проекты конкурируют за специалистов, бюджет и управленческое внимание. Но эти конфликты становятся заметны, когда сроки уже сдвинулись, а расходы выросли.
Когда в компании нет системного управления проектами
Проявляются четыре характерных симптома:
- Отсутствие контроля. Руководитель не может в моменте ответить на простые вопросы: какие статусы по ключевым проектам, укладываемся ли в сроки, что происходит прямо сейчас. Информация живет в головах исполнителей, разрозненных файлах и почтовой переписке.
- Отчетность собирается вручную. Данные стягиваются из excel-файла, переписки или устных опросов. Подготовиться к совещанию быстро невозможно, и само совещание превращается в разбирательство. Первые полчаса команда не принимает решения, а выясняет, что происходит.
- Непонятно, как используются ресурсы. Кто и насколько загружен, кого можно высвободить под новый приоритетный проект. Решения о запуске новых инициатив принимаются вслепую, перегруз ключевых специалистов обнаруживается по факту срыва сроков.
- Нет единой методологии. У каждого руководителя проекта свои правила, основанные на его опыте и привычках. Результат проекта начинает зависеть от личности конкретного менеджера, а не от выстроенного процесса. Лучшие практики не накапливаются: уходит человек, и вместе с ним уходит и экспертиза.
Увидев эти симптомы, руководители часто решают, что нужна программа для управления проектами, но покупка софта сама по себе ничего не исправит. Сначала нужно договориться о правилах запуска и закрытия проектов, статусах, периодичности отчетности и критериях приоритизации. А потом уже выбрать инструмент, который эту методологию закрепляет и делает исполнение прозрачным. В таком случае компания приобретает не просто очередной софт, а порядок, благодаря которому реализуется стратегия.
Любая стратегия развития существует в конкретных проектах, и если проекты не управляются, стратегия не исполняется. Работающая система дает руководителю то, что я называю единой версией правды: одно окно, где видно реальное состояние всего портфеля. Каждый проект находится в понятной зоне: зеленой, желтой или красной, и внимание руководства достается тем инициативам, которые действительно в нем нуждаются.
Есть ли в компании контроль над проектами – самодиагностика
Задайте себе и своей команде пять проверочных вопросов:
- Сколько сейчас активных проектов? Если для ответа приходится собирать информацию вручную, это повод разобраться, как устроено управление портфелем.
- По каждому ли проекту определены целевые показатели? Проект без KPI невозможно признать ни успешным, ни провальным.
- В какой зоне находится каждый проект: зеленой, желтой, красной? Когда статусная модель отсутствует, отклонения обнаруживаются слишком поздно.
- Сколько времени занимает подготовка сводного отчета по портфелю? Больше одного дня – значит, отчетность собирается вручную и к моменту совещания устаревает.
- Какие задачи по управлению проектами сейчас приоритетны для компании? Отсутствие ответа означает, что тема развития портфеля вообще не находится в фокусе руководства.
Если хотя бы на два вопроса из пяти уверенного ответа нет, компания управляет своим портфелем на ощупь.
Выводы
Управление проектами, по сути, это управление развитием бизнеса. Компания растет ровно настолько, насколько успешно завершаются ее проекты, поэтому наведение порядка в проектном портфеле стоит рассматривать не как задачу отдельной команды, а как прямую ответственность первого лица, ведь речь идет именно о том, будет ли исполнена стратегия.
Также читайте:
А почему в компании должен быть механизм системного управления проектами?
Зачем ей это нужно?
Это будет определяться тем, чем занимается компания. Если основной бизнес - проектное управление, то это будет частью бизнес-модели компании.
С другой стороны - статья, вроде как, про управление портфелем проектов, но при этом рекомендует знать, сколько проектов в портфеле и в какой они стадии. Мне видится, что это - базовая компетенция менеджера проектов, особенно - если он сертифицирован по РМР. При этом нарушения сроков и бюджетов могут вполне быть связанными с экзогенными факторами и находиться вообще вне периметра воздействия менеджера. Бонусом в заключении смешаны ответственность СЕО и мандат проектного офиса. Текст у меня также вызвал множество "зачем" и "почему", но преимущественно по самой концепции такого проектного менеджмента.
У меня возникло ощущение непонятности из-за того, что при использовании проектного управления в компании (если это не профанация) непонятно, какой уровень применения ПУ возможен в текущей работе при наличии таких проблем.
По умолчанию можно предположить две ситуации (это гипотеза): 1) компания использует ПУ как основной элемент (например, в ИТ-разработке); 2) ПУ существует как отдельный контур / проектный офис.
Но ситуации, которые описывает автор, — мне непонятно, где они там встречаются. Если в компании бардак с точки зрения управления, то ПУ — это миф, в котором, возможно, висят сами сотрудники.
Использование проектного офиса — эта логика мне понятна. Но если это происходит в описанном контексте, то мне вообще непонятно, что там происходит в компании.
Если речь о PPM, то обычно это уровень PMO как выделенного подразделения со своей зоной ответственности и ресурсами.
Сложно представить, что при этом руководитель (чего?) не может ответить на вопросы о статусе проекта(ов). А кто может?
Решение о начале проекта принимается после подготовки и подписания соответствующего контракта - если проект внешний - или какой-то процедуры для внутренних проектов. Сами собой проекты не запускаются. Их не приносит аист. Их не находят в капусте. Бюджеты и другие финансовые показатели, сроки, содержание, ресурсы, критерии успеха и прочие параметры документируются на самых ранних стадиях. Финансисты видят затраты по проекту и планируемые бюджеты еще до официального начала проекта.
Согласен, вопросов много.
Даже нет смысла спрашивать про KPI и цвета зон. Но что-то вызывает недоумение. Например:
Кто понимает и мог бы подсказать, что это за тема? Кто, когда и с кем её обсуждает?
У меня возникло ощущение, что автор вообще плохо очертил понятие проекта.
Проект можно сделать много из чего, возникает вопрос: что является проектом, а что нет, и как это определить.
Ну вообще существует определение проекта:
Например стройка дома - проект.
Поддержание дома в жилом состоянии - процесс.
Интересно, насколько глубоко можно разбить процесс на проекты.
И какие процессы насколько могут быть разбиты.
Например, годовая профилактика водоснабжения — это процесс или проект?
Читаем стандарты PM. Это не тайна. Все определения давно и хорошо написаны.
Если говорить о PPM, то основные вопросы возникают - иногда неоднократно - с расстановкой текущих приоритетов и управлением ограниченными ресурсами. Мультизадачность - очевидное зло.
Мониторинг каждого проекта в портфеле в зоне ответственности его менеджера. Он может использовать любые стандартные корпоративные инструменты визуализации или свои собственные. Науки здесь нет.
Процесс.
Однако если вы реконструируете систему водоснабжения - это уже проект
Да-да, но я писал про статью, а не про стандарты РМ.