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

Итак вы стали руководителем проекта. Означает ли это, что нужно обязательно и немедленно составлять план по вехам, подробный календарный план с диаграммой Ганта, матрицу ответственности, план по ресурсам, бизнес-кейс и так далее? Времени на подготовку и актуализацию этих документов уйдет много и у проджекта и у команды, но поможет ли это проекту стать успешнее!? Помимо требований родной организации прежде всего надо разобраться, что делает ваш проект проектом, требующим особых практик, методов и инструментов управления. Как выбрать именно те инструменты, которые помогут достичь лучших результатов, а не просто съедят драгоценное время? Как понять, где без них обойтись нельзя, а где проектный менеджмент полностью или частично — не что иное как “натягивание совы на глобус”? Читайте в статье ниже.
Начнем с так часто используемого определения проекта:
«Проект — временный комплекс мероприятий, который предпринимается для создания уникального продукта, сервиса или результата» (PMBok)
В определении нет никакой ошибки, но возникает вопрос: если срочность критерий понятный, то как же понять, что продукт, который создается, уникален? Если продукт кажется уникальным, то это сразу проект? А в случае его не уникальности он не требует использования проектных методов?
В вопросе отнесения деятельности к проектной опасно опираться только на уникальность продукта, так как критерий этот, толковаться может по-разному. Для организаций это вообще беда: когда нужны деньги — любая деятельность становится проектом, а если не нужна “бюрократия” и “прозрачность”, то не проект и так далее.
Если уж использовать методы и инструменты управления проектами, то только по отношению к тем “проектам”, которые относятся к наиболее рискованным, связанным с потенциально большими финансовыми и репутационными потерями, успех которых негарантирован, то есть по-простому к сложным. Именно в таких проектах не грех применить метод «набегающей волны», составить диаграмму Ганта, реестр рисков и много чего ещё. Почему? Все дело в том, что сложность приводит к более высокой вероятности возникновения проблем и ошибок, для профилактики которых и существует большинство инструментов и практик проектного менеджмента. Беда в том, что ни в одном стандарте по проектному менеджменту ничего не говорится ни про сложность проекта, ни про проблемы, которые она вызывает.
В отличие от уникальности, которая чаще всего упоминается в известных определениях проекта, критерии сложности конкретны, и, согласно Модели управленческой сложности проектов, существуют четыре группы факторов, усложняющих что-то, что мы называем проектом:
- масштаб,
- неопределенность требований,
- новизна технологий,
- влияние внешних факторов.
Масштаб
Масштабный проект — тот, где всего и много. Если говорить точнее, то на масштабность проекта указывает вот что:
- Большая длительность проекта
Например проект по строительству здания парламента Шотландии: строительство длилось больше шести лет и за это время сменились архитектор, члены парламента и их требования к продукту, а из-за событий 11 сентября 2001 года, пересмотрели концепцию безопасности, что привело к изменениям плана проекта. Как итог, бюджет проекта превышен в 10 раз, результат сдан на полтора года позже, чем планировали, а вместо благодарности получили уголовное дело о перерасходе средств (уверены, даже, если вы не строили парламенты, то сталкивались с подобной ситуацией).
Поэтому чем дольше длится проект, тем больше вероятность изменений в нём (стейкхолдеров, требований, технологий, законодательства и т.д.), а значит нужно держать руку на пульсе (читать — применять проектные методы).
- Количество участников проекта
Здесь речь идет о количестве организаций, которые одновременно участвуют в проекте. Для внутренних проектов учитывается количество структурных подразделений, а для международных — количество стран, организации из которых участвуют в проекте. Если вы привыкли работать с одной-двумя организациями, а теперь таких организаций пять-шесть, то риск реализации такого проекта вырастет из-за роста сложности.
- Количество стейкхолдеров проекта
Стейкхолдеры проекта — люди, которые заинтересованы в проекте или которых проект затрагивает. Такие люди могут не принимать в проекте деятельного участия, да что там, могут даже не знать о том, что по отношению к данному проекту являются стейкхолдерами А потом внезапно узнают и, как это часто случается, в конце проекта предъявляют свои требования со всеми вытекающими (переделки, дополнительные затраты, срыв сроков и так далее).
Задача руководителя проекта состоит в том, чтобы стейкхолдеров найти и обезвредить, самыми мирными, проектными способами, конечно. Об этом будет отдельная серия постов, а сегодня, говоря о сложности проекта важно запомнить: чем больше стейкхолдеров в проекте, чем больше риск противоречий в их интересах и ожиданиях, тем сложнее управлять таким проектом.
- Объем финансирования
Здесь учитывается сколько выделено денег на весь проект и ближайший год. Получается, что чем больше денег, тем серьезнее проект контролируется, но чтобы не ошибиться, оценивайте ещё и вот что:
- насколько затраты подвержены влиянию изменений внутри проекта (тех, что уже происходят или тех, которые только ожидаются), например если будет запущен еще ряд проектов, повлияет ли это на финансирование вашего?
- есть ли какие-то внешние факторы, которые в будущем повлияют на объем финансирования (или на источники финансирования), например повлияет ли на это изменение регулирующего деятельность законодательства? Или смена собственника?
В итоге: если бюджет больше, чем средний размер проекта в вашей организации, если финансирование и его источники подвержены влиянию внутренних изменений и внешних факторов, то ставьте “плюсик” напротив словосочетания “сложный проект”.
- Много работ и объектов управления
Критерий в таком виде звучит очень уж общо, а если конкретно, то обращать внимание рекомендуется вот на что:
- Много ли создается (или внедряется готовых) результатов
Например, проект по запуску службы клиентской поддержки, где одновременно создается информационная система, набирается и обучается работе с ней персонал, создается нормативно-регламентная база, подготавливается помещение для работы будет считаться сложным, как раз из-за множества создаваемых результатов
- Много ли у результата проекта пользователей
У системы электронного документооборота в отдельно взятой организации с численностью 90 человек пользователей значительно меньше, чем например у приложения, по предоставлению государственных услуг жителям крупного города. Соответственно меньше масштаб и требования, а значит, не так сложно
- Сколько систем, документов и других объектов изменятся при разработке результата проекта
И снова система электронного документооборота, при разработке которой, для корректной организации процесса делопроизводства, вносятся изменения в системы файлов и папок, для создания документов придется использовать специальные шаблоны, вносить изменения в регламентные документы и сделать много чего ещё. Чувствуете, как сложно?
- Количество требуемых компетенций.
Представьте, в одном и том же проекте нужно: разработать и внедрить систему, описать процессы, составить нормативную документацию и пройти не поддающиеся подсчету бюрократические кордоны. Всё это разные области профессиональных компетенций и чем таких областей больше, тем сложнее их сочетать.
Ну что друзья, с масштабом закончили, а впереди ещё три группы факторов сложности, которые помогут понять в каких областях какие методы использовать. Подписывайтесь, чтобы не пропустить!
Ещё больше нового опубликуем в телеграмм канале Уж&Ёж, где расскажем о гибридном управлении проектами, научим совмещать лучшие инструменты разных проектных методологий и при этом не усложнить себе жизнь.
Присоединяйтесь к чату канала, там всегда можно высказаться на проектную тему. А если вы начинающий или опытный специалист в сфере project management и хотите рассказать о своем опыте, пишите: @Malakhov_Andrey, создадим полезное вместе 🙂


