(Вестник № 15, 2019, ISSN 1819-6721, доклад http://www.pmsoft.pro/)
Автор: Анна Моисейкина, Начальник отдела проектного контроля и отчетности АО «НоваВинд»
Аннотация: Из проекта в проект даже заказчики с достаточной зрелостью в области проектного управления совершают стандартные ошибки на разных этапах проекта. Данная статья описывает практические советы по тому, как этих ошибок избежать. Анализ базируется на богатом опыте участия в проектах различной сложности на стороне заказчика.
Когда говорят о преимуществах развития проектного управления, обычно концентрируются на минимизации срывов сроков, повышении эффективности взаимодействия между подрядчиком и заказчиком, оптимизации и прозрачности основных процессов. Практика показывает, что даже после внедрения методологии и информационной системы для управления проектами, сроки продолжают срываться, проектные команды работают в режиме «тушения пожара», а решения принимаются без учета аналитики по проекту.
Основываясь на опыте, причина вышесказанного кроется в том, что на всех этапах реализации проекта допускается ряд простых, но весьма значимых ошибок, которые в конечном счете и приводят к проблемам. Попробуем разобраться, какие ошибки чаще всего делает заказчик, и как их можно избежать.
Для проведения оценки зависимости количества ошибок от стадии проекта, были выявлены и сформулированы проблемы, с которым сталкиваются участники при реализации проекта.
Как видно из рисунка 1, наибольшее количество ошибок совершаются на стадии планирования, и, как следствие, на стадии исполнения проекта. Попытаемся разобраться в причинах такой тенденции.
Процесс инициации проекта
Если мы говорим о стадии инициации, то основные причины ошибок, в том числе и на последующих этапах, связаны с техническим заданием на проектирование. Как показывает практика, зачастую, даже если в организации есть документ, описывающий и регламентирующий принципы составления ТЗ, обычно он используется и обновляется редко. Однако именно регламент на подготовку процесса проектирования позволяет проверить, соблюдены ли в ТЗ необходимые требования, есть ли нужные разделы, а ведь именно техническое задание является основополагающим документом в проекте. Так что я рекомендую проверять наличие такого регламентирующего документа и его актуальность, а если его нет – разработать.
Отдельно хочется отметить, что разработка Технического задания требует конкретных навыков, опыта и вовлеченности в проект. К сожалению, далеко не всегда работа над ТЗ поручается сотруднику с достаточной компетенцией – чаще всего подход к разработке ТЗ носит формальный характер с расчетом на то, что в ходе реализации проекта требования, заложенные в техническом задании, подвергнутся корректировке. В результате, изначально разрабатывают ТЗ низкого качества, не учитывая многие требования, что в дальнейшем приводит к неконтролируемому увеличению объема проектирования. Отсутствие чек-листа для проверки полноты составления ТЗ может привести к срыву проекта в принципе.
Кроме того, нужно уже на этапе инициации проекта учитывать требования всех заинтересованных сторон и специализированных подразделений, таких как Службы главного энергетика, Службы главного метролога. В одном из проектов, неожиданно в процессе выполнения работ поступил запрос от смежной службы о необходимости замены опор печей. В качестве исходных данных проектировщику потребовались чертежи 1960-го года выпуска. Имея ввиду срок давности, чертежей не оказалось. Единственным выходом была контрактация отдельной организации, которая провела бы обследование печей и разработала чертежи. В результате чего произошел сдвиг сроков разработки разделов. Если бы, то самое смежное подразделение участвовало в разработке и согласовании технического задания, это требование было бы учтено, и процесс обследования начался раньше, что помогло бы избежать срыва сроков.
Процессы планирования
Процессы планирования одни из самых важных этапов проекта, однако именно в рамках их реализации часто не учитываются очевидные моменты:
Начнем с простого: если бы у нас хотя бы на одном проекте был план управления проектами…
Каждый уважающий себя специалист в области проектного управления, оперирует постулатами Свода знаний по управлению проектами PMBoK. Почему же на практике единицы проектов начинаются с разработки Плана управления проектами – того самого основополагающего документа организации процессов управления, где фиксируется основные показатели и дисциплины проекта: схемы взаимодействия участников, содержание, подходы к планированию, требования к организации совещаний и тд. Это только на первый взгляд может показаться, что такие вещи менее важны, чем выбор квалифицированной подрядной организации, но по факту эффективность коммуникаций с тем же самым подрядчиком значительно повышает эффективность выполнения проекта.
Например, в одном из проектов на стадии контрактации выполнение инжиниринговых пусконаладочных работ было включено в объем подрядчика на СМР. Уже на стадии реализации столкнулись с отсутствием достаточной компетентности у подрядной организации в данном виде работ. В результате было потрачено много времени на выработку решения, изменения условий текущего договора и контрактации с отдельной организацией, что привело к сдвигу сроков и увеличению бюджета. Если бы на стадии планирования проектной командой был составлен план управления проектами, где организационная схема проекта является неотъемлемым разделом, такой ошибки можно было избежать.
Это же касается и требований к качеству выполнения работ: когда начались строительно-монтажные работы, огромное количество времени было потрачено на определение реестров исполнительной документации, предоставляемой подрядчиком ввиду технологической сложности, выполняемых работ. Все детали мы выясняли по ходу выполнения работ, теряя время. Если бы проектная команда изначально сформировала и утвердила унифицированный перечень исполнительной документации, этого бы не случилось.
Еще один тонкий дискуссионный вопрос – резерв по времени. На практике понимание этого понятия весьма спорно. Как правило, приходиться сталкивается с двумя крайностями: проект имеет навязанную жесткая дату завершения без каких-либо временных резервов на риски; вторая крайность – наличие у одного проекта нескольких целевых планов с большой разницей по времени выполнения, что, наоборот, свидетельствует о необоснованности составления графиков и выбора временных рамок производства работ. Вывод - резерв по времени нужен, но лучше выделять, основываясь на накопленной по проектам информации.
Особого внимания заслуживает вопрос организации проектной команды. В этом, казалось бы, понятном процессе часто совершается множество ошибок. И самая главная – отсутствие продуманного подхода к нему.
В частности, в при реализации проекта реконструкции проектная команда формировалась «лавинообразно». Была кем-то когда-то разработанная структура проектного офиса, но в ходе выполнения проекта выяснилось, что профильных специалистов не хватает. Приходилось нанимать дополнительный персонал, привлекать людей из других структурных подразделений в условиях ограниченных временных рамок. Изначально в команде проекта насчитывалось 13 человек, но уже к середине проекта - 35. Мы теряли время и слаженность работы команды, когда приходилось вводить каждого нового человека в проект. Если бы на первоначальном этапе к вопросу подошли более серьезно, этого можно было избежать.
Подчеркну: при формировании команды в первую очередь должны учитываться требования к компетенции участников. Зачастую же команды формируются по остаточному принципу: набираются люди, которые освободились в связи с окончанием предыдущего проекта. Однако при таком принципе подбора можно столкнуться с нехваткой необходимых для конкретного проекта компетенций, и в результате придется потратить время, силы и деньги на то, чтобы обучить существующих специалистов или найти тех, кто сможет заполнить пробелы. Это мешает эффективному функционированию проектной команды, поэтому требования к компетенциям нужно закладывать еще на этапе формирования команды.
Календарно-сетевые графики – основа управления проектами, поэтому говорить о целесообразности их использования кажется бессмысленным. На практике же графики используются далеко не всегда. К примеру, при реализации крупного проекта какое-то время календарно-сетевой график представлял собой красивую картинку, висевшую в штабе только для того, чтобы показать его формальное наличие. Подрядчик всегда считает график формальностью, обязательной, но не имеющей отношения к действительности.
Иногда графиков становится настолько много, что их количество тоже превращается в проблему. В какой-то момент при реализации проекта отдел планирования и контроля одновременно вел 25 графиков, и на регулярной основе проводилось отдельное совещание по обсуждению графика составления графиков. В практике была работа по разработке графика суммарной длительностью 6 часов, где длительность операции составляла примерно 20 минут, хотя понятно, что никакой смысловой нагрузки такой график не нес, так как факт собирался один раз в сутки.
Чтобы избежать таких ситуаций, необходимо, во-первых, добиться понимания у всех заинтересованных сторон того, зачем нужен график и как с ним работать. Во-вторых, необходимо пресекать все необоснованные требования по составлению графиков, иначе наступает момент, когда вся команда работает только на составление и актуализацию графиков. Помочь решить эту задачу может план управления проектом, где должны быть определены правила игры относительно того, какие графики нужны и сколько их должно быть, а также включение четких требований по организации разработки, предоставления и актуализации в договор с подрядчиком на выполнение работ.
Замечу, что графики, четкие и понятные, особенно важны при организации взаимоотношений с подрядчиками. В одном из проектов проектов задержка выдачи проектной документации составила порядка 6 месяцев, что привело к тому, что документацию по разделам получали уже в процессе стройки. Проектировщик при этом считал виноватым заказчика, который не предоставил РКД. Если бы был зафиксированный график с проектировщиком, то можно было бы точно определить, где зона ответственности проектировщика, а где – заказчика.
Процесс исполнения проекта
В ходе выполнения проекта можно выделить следующие основные ошибки, повторяющиеся из проекта в проект:
· недостаточность исходных данных для подрядчика;
· отсутствие методологии и низкая проектная зрелость исполнителя работ;
· недостаточная детализация и проработка пуско-наладочных работ;
· «пожиратели» времени.
В ходе реализации проекта очень часто заказчик в срыве сроков винит в первую очередь подрядную организацию, но, если провести независимую оценку причин, можно сделать вывод, что заказчик точно также виноват в срыве дат завершения. Например, на одном из последних проектов руководство требовало от подрядчика ускорить строительно-монтажные работы, но в тоже время заказчик с значительным опозданием выдавал чертежи в производство работ. Поэтому в первую очередь необходимо отслеживать полноту и своевременность предоставления подрядчику всех необходимых ему данных.
Кроме того, даже если у заказчика есть информационная система управления проектами и методология в большинстве случаев этого недостаточно для эффективного управления проектом, так как в 80% случаев даже очень крупные подрядчики находятся на самом низком уровне развития проектного управления: отсутствует какая-либо методология управления проектами. Даже если планировщики заказчика, имея достаточную компетенцию для планирования работ, подрядчик будет просто не готов играть по этим правилам.
Очень часто заказчик сталкивается с тем, что подрядчик отказывается вести графики в Oracle Primavera или каком-либо другом специализированном программном комплексе, обосновывая нехваткой людей или стоимостью прохождения обучения. Мы попытались найти выход из ситуации, сами обучили сотрудников подрядчика, но в конечном счете, выделенный для планирования инженер, выполняет огромное количество других функций – отвечает за закупки, является ГИПом, специалистом ПТО и т.д. В итоге работы планировал заказчик, не обладая полной информацией о доступности ресурсов и техники подрядных организаций.
Отдельно хочется уделить внимание планированию пусконаладочных работ. Чаще всего детально расписывается график строительно-монтажных работ, в тоже время по пусконаладочным работам детализация составляет в лучшем случае 5-10 операций графика. В большинстве проектах пусконаладочные работы представляют собой сложнейший комплекс инженерных, электрических, инструментальных работ, которые необходимо состыковать между собой, что требует детальной проработки программы испытаний по каждому виду работ и их взаимосвязи с монтажной готовностью объекта.
Еще один важнейший момент – выбор подрядной организации на пусконаладочные работы необходимо начинать как можно раньше, для того, чтобы обеспечить больше времени на проработку программ испытаний.
К сожалению, часто проекты ведутся в режиме «тушения пожара». Проектные офисы часто работают по 14-16 часов в день. Если разобраться, куда уходит основное время, то можно выделить огромное количество совещаний. Опять же возвращаясь к плану управления проектами, уже на начальном этапе можно было определить и зафиксировать: какие совещания и с какой периодичностью должны проводиться, и избежать таких временных затрат. Также не стоит пытаться решить все проблемы сразу: совещание на 20 специалистов из разных подразделений не принесет результата – большую часть времени люди просто будут ждать своей очереди выступить.
Еще одна проблема может связана с отсутствием вовлеченности и мотивации команды. В этом случае будет работать подход «не моя зона ответственности». Схожая позиция – отказ предоставлять информацию без формализованных запросов или служебных записок. В режиме ограниченных сроков такое отношение отнимает много времени, поэтому руководителю проекта необходимо работать над созданием здоровой атмосферы в коллективе.
Отдельно хотелось бы выделить выдачу «срочных» заданий, которые нарушают планы на день, и далеко не всегда являются действительно срочными. Во избежание возникновения таких ситуаций необходимо обсуждать действия с руководителем проекта или постановщиком задачи, выделяя то, что действительно важно.
Процесс мониторинга и контроля
Значимость этого процесса сложно переоценить, и несмотря на это многие просто пренебрегают им – это самая большая ошибка.
В большинстве проектов руководители замыкают все процессы на себя, принимают решения, основываясь только на личном опыте без аналитической поддержки со стороны отчетности, что приводит к неэффективному управлению, и, как следствие, к нарушению сроков и сбою процессов.
При реализации проектов только компании с высоким уровнем зрелости в проектном управлении уделяют внимание процессам управления изменениями. В международной практике управление изменениями является неотъемлемой частью реализации проекта, что повышает прозрачность причин принятых решений, инициаторов и ответственных за их принятия, влияния их на основные параметры проекта.
Процессы завершения проекта
В большинстве случаев не принято подводить итоги проектов, создавать архивную базу с типовыми фрагментами графиков выполнения работ, нормативной базы, перечня выявленных рисков. А между тем, накопленные в процессе мониторинга и контроля знания позволят управлять изменениями, найти причины отклонений в сроках и затратах, и в дальнейшем путем совершенствования организационных процессов реализовывать проекты более успешно. Так что в любом случае необходимо сделать несколько шагов, чтобы систематизировать извлеченные уроки– не зависимо от специфики и размера проекта.
Оставьте запрос для оценки вашего проекта pmsoft@pmsoft.ru
Пишите в комментариях, если у вас (вашей компании) в этом есть насущная потребность. Запланируем общение онлайн или другим возможным способом.
Совместно найдем оптимальное решение, поделимся актуальными практиками/ кейсами и поддержим в текущей ситуации.
Больше информации на http://www.pmsoft.ru/
#pmsoft #консалтинг #импортозамещение #управлениепроектами #стоимостнойинжиниринг #цифроваяплатформа #суп
