25 ноя 2021

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

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

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

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

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

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

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

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

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

Масштаб

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Авторы статьи:
Смотрите также:
16 Апр 2024
Что такое декомпозиция и чем она отличается от других видов планирования
Декомпозиция – это метод разделения большой цели, продукта, задачи, работы или процесса на маленькие части, этапы, подзадачи. Часто декомпозицию применяют для составления плана работ и контроля реализации большого сложного проекта. Как её применять, читайте в этой статье.
15 Апр 2024
Иерархическая структура работ проекта: что это и как ее создать
Иерархическая структура работ (ИСР), которую также называют WBS (расшифровывается как Work Breakdown Structure) или структурной декомпозицией работ – это метод планирования работ по проекту, с помощью которого можно “съесть слона по кусочкам”. ИСР помогает достичь цель, разбивая ее на задачи и подзадачи. 
22 Мар 2024
Бюджет проекта: суть и правила составления
Недавнее исследование Outlook показало, что вопрос финансов и прогнозирования бюджета входит в тройку самых распространенных проблем в области управления проектами.
Подписаться на рассылку
Высылаем анонсы статей и полезные материалы
Прокомментировать статью
Текст сообщения
Имя, Отчество, Фамилия
Email

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

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

Наверх
Здравствуйте! Если возникли вопросы, мы на связи.
Скопировано в буфер обмена