+7 (926) 827 3222
25 ноя 2021

«Оно вам надо?» или когда проектные методы действительно работают. Часть 1

Итак вы стали руководителем проекта. Означает ли это, что нужно обязательно и немедленно составлять план по вехам, подробный календарный план с диаграммой Ганта, матрицу ответственности, план по ресурсам, бизнес-кейс и так далее? Времени на подготовку и актуализацию этих документов уйдет много и у проджекта и у команды, но поможет ли это проекту стать успешнее!? Помимо требований родной организации прежде всего надо разобраться, что делает ваш проект проектом, требующим особых практик, методов и инструментов управления. Как выбрать именно те инструменты, которые помогут достичь лучших результатов, а не просто съедят драгоценное время? Как понять, где без них обойтись нельзя, а где проектный менеджмент полностью или частично — не что иное как “натягивание совы на глобус”? Читайте в статье ниже.

Начнем с так часто используемого определения проекта:

«Проект — временный комплекс мероприятий, который предпринимается для создания уникального продукта, сервиса или результата» (PMBok)

В определении нет никакой ошибки, но возникает вопрос: если срочность критерий понятный, то как же понять, что продукт, который создается, уникален? Если продукт кажется уникальным, то это сразу проект? А в случае его не уникальности он не требует использования проектных методов?

В вопросе отнесения деятельности к проектной опасно опираться только на уникальность продукта, так как критерий этот, толковаться может по-разному. Для организаций это вообще беда: когда нужны деньги — любая деятельность становится проектом, а если не нужна “бюрократия” и “прозрачность”, то не проект и так далее. 

Если уж использовать методы и инструменты управления проектами, то только по отношению к тем “проектам”, которые относятся к наиболее рискованным, связанным с потенциально большими финансовыми и репутационными потерями, успех которых негарантирован, то есть по-простому к сложным. Именно в таких проектах не грех применить метод «набегающей волны», составить диаграмму Ганта, реестр рисков и много чего ещё. Почему? Все дело в том, что сложность приводит к более высокой вероятности возникновения проблем и ошибок, для профилактики которых и существует большинство инструментов и практик проектного менеджмента. Беда в том, что ни в одном стандарте по проектному менеджменту ничего не говорится ни про сложность проекта, ни про проблемы, которые она вызывает.

В отличие от уникальности, которая чаще всего упоминается в известных определениях проекта, критерии сложности конкретны, и, согласно Модели управленческой сложности проектов, существуют четыре группы факторов, усложняющих что-то, что мы называем проектом: 

  • масштаб, 
  • неопределенность требований,
  • новизна технологий,
  • влияние внешних факторов.

Масштаб

Масштабный проект — тот, где всего и много. Если говорить точнее, то на масштабность проекта указывает вот что: 

  • Большая длительность проекта

Например проект по строительству здания парламента Шотландии: строительство длилось больше шести лет и за это время сменились архитектор, члены парламента и их требования к продукту, а из-за событий 11 сентября 2001 года, пересмотрели концепцию безопасности, что привело к изменениям плана проекта. Как итог, бюджет проекта превышен в 10 раз, результат сдан на полтора года позже, чем планировали, а вместо благодарности получили уголовное дело о перерасходе средств (уверены, даже, если вы не строили парламенты, то сталкивались с подобной ситуацией).

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

  • Количество участников проекта

Здесь речь идет о количестве организаций, которые одновременно участвуют в проекте. Для внутренних проектов учитывается количество структурных подразделений, а для международных — количество стран, организации из которых участвуют в проекте. Если вы привыкли работать с одной-двумя организациями, а теперь таких организаций пять-шесть, то риск реализации такого проекта вырастет из-за роста сложности.

  • Количество стейкхолдеров проекта

Стейкхолдеры проекта — люди, которые заинтересованы в проекте или которых проект затрагивает. Такие люди могут не принимать в проекте деятельного участия, да что там, могут даже не знать о том, что по отношению к данному проекту являются стейкхолдерами А потом внезапно узнают и, как это часто случается, в конце проекта предъявляют свои требования со всеми вытекающими (переделки, дополнительные затраты, срыв сроков и так далее).

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

  • Объем финансирования

Здесь учитывается сколько выделено денег на весь проект и ближайший год. Получается, что чем больше денег, тем серьезнее проект контролируется, но чтобы не ошибиться, оценивайте ещё и вот что: 

  1. насколько затраты подвержены влиянию изменений внутри проекта (тех, что уже происходят или тех, которые только ожидаются), например если будет запущен еще ряд проектов, повлияет ли это на финансирование вашего? 
  2. есть ли какие-то внешние факторы, которые в будущем повлияют на объем финансирования (или на источники финансирования), например повлияет ли на это изменение регулирующего деятельность законодательства? Или смена собственника?

В итоге: если бюджет больше, чем средний размер проекта в вашей организации, если финансирование и его источники подвержены влиянию внутренних изменений и внешних факторов, то ставьте “плюсик” напротив словосочетания “сложный проект”.

  • Много работ и объектов управления

Критерий в таком виде звучит очень уж общо, а если конкретно, то обращать внимание рекомендуется вот на что:

  • Много ли создается (или внедряется готовых) результатов

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

  • Много ли у результата проекта пользователей

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

  • Сколько систем, документов и других объектов изменятся при разработке результата проекта

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

  • Количество требуемых компетенций. 

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

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

Ещё больше нового опубликуем в телеграмм канале Уж&Ёж, где расскажем о гибридном управлении проектами, научим совмещать лучшие инструменты разных проектных методологий и при этом не усложнить себе жизнь.

Присоединяйтесь к чату канала, там всегда можно высказаться на проектную тему. А если вы начинающий или опытный специалист в сфере project management и хотите рассказать о своем опыте, пишите: @Malakhov_Andrey, создадим полезное вместе 🙂

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

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

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

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

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

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