ITOGO
+380 (44) 496-00-46


ПРОЕКТ АВТОМАТИЗАЦИИ «в столбик» (ч.3)

Приветствую Вас!
В прошлый раз мы остановились на том, что необходимо уделить особое внимание фигуре Технолога, и его "погружению" в проблематику проекта. Сегодня же предлагаю поговорить других аспектах выполнения продолжительных, многоэтапных и технологически сложных проектов. При выполнении длительных проектов рабочую группу проекта, кроме всего прочего подстерегает еще одна «опасность» или, если хотите, угроза – проектные документы, созданные на начальных фазах проекта, имеют свойство утрачивать свою актуальность. В особенности это касается документов, которые описывают предлагаемое решение или требование к решению по какой-либо локальной задаче. Обычно это случается незаметно для глаз даже опытного менеджера проектов: на собрании с участием руководства компании Заказчика принимается решение, которое напрямую не затрагивает задачу или вопрос, описанный одним из созданных ранее документов. Но при дальнейшем детальном рассмотрении оказывается, что принятое решение в одной из своих «плоскостей» противоречит условиям, которые были зафиксированы ранее, либо же происходит их усложнение. В этом случае недостаточно зафиксировать решение Проектного комитета в протоколе совещания. Уже на этапе написания протокола Менеджер Проекта автоматически должен добавит пункт в «Решили» «Произвести актуализацию проектных/технологических документов в связи с решением, изложенным в п.№__». Актуализацию проектных документов выполняет Менеджер Проекта, технологические документы актуализируются одним из аналитиков проекта (возможна схема закрепления документов за конкретными аналитиками). Необходимо помнить, что актуализация документов требует времени, а время - это деньги. Следующим вопросом является: "Кто оплатит изменение технологии, решение о котором принял Проектный Комитет?" А трудозатраты могут быть достаточно ощутимыми. Поэтому, вопрос на выделении бюджета на то или иное "изменение" должен быть оговорен на том же совещании, когда и было принято решение о внесении изменений в согласованную ранее технологию или какой-либо документ. Если этот вопрос не поднять, эта работа будет проделана бесплатно, а ответственность за ее негативное влияние на сроки всего проекта будет лежать на Менеджере Проекта.
Вопрос внесения изменений в технологию «налету» (без детальной проработки и документирования) необходимо категорически исключать уже на ранних стадиях общения с Клиентом. Эту мысль необходимо доносить до Заказчика каждый раз, как только он захочет добавить очередной «бантик», связанный с «динамичностью его бизнеса» и прочими «вескими» причинами. Актуальные согласованные документы, желательно с "мокрыми" подписями участников Проектного Комитета, в этом случае должны быть преградой на пути хаоса, который вносится «волевыми» решениями Заказчика.
Вы должны понимать, что если Вы пойдете на поводу у Заказчика и сделаете «доброе дело» быстро и без лишней бумажной волокиты, Вы ставите под угрозу весть проект, и никто кроме Вас за это отвечать не будет. Даже если документирование и детальный анализ влияния решения Проектного Комитета потребует переносов глобальных сроков проекта, нельзя соглашаться на переход в режим работы «на коленках» - это верный путь к провалу.
На завершающих стадиях сложных проектов неизбежно накапливается целый список требований и работ, которые, по мнению Заказчика, должны непременно быть выполнены. При этом перед Менеджером Проекта со стороны Исполнителя стоит задача контролировать попадание этих задач в границы выполняемого проекта. По возможности он должен отстаивать первоначальные границы, т.к. именно они закладывались в календарные планы работы не только проектной группы, но смежных подразделений и, возможно, внешних подрядчиков. Он как голкипер должен отбивать атаки на ворота совей команды – границ проекта. Каждое пропущенное дополнительное требование – это гол! Все обязательные для реализации требования Заказчика должны качественно документироваться. По договоренности сторон дополнительные пожелания могут быть реализованы в рамках следующих проектов. Если требование критично для старта проекта и «гол» был пропущен, это требование должно быть зафиксировано в соответствующих проектных или технологических документах, а календарные сроки выполнения работ и бюджеты пересмотрены. Если допускать внесение изменений в обход соответствующей процедуре, границы проекта размываются, проект становится неуправляемым и в один «прекрасный момент» проектные работы превратятся в хаотическое затыкание дыр.
Качественно составленные, актуальные и работающие проектные документы это один из механизмов контроля завершения проекта. Именно они в итоге должны выступать мерилом завершенности проекта. Если возникает подозрение, того что критериями выполнения проекта является или может являться некая другая шкала, например, «удовлетворение потребностей клиента» - необходимо инициировать актуализацию критериев завершения проекта через Проектный Комитет со всеми вытекающими последствиями (изменение сроков, бюджетов и т.п.). Эта процедура позволит контролировать статус-кво на проекте.
Необходимо помнить, что проект модернизации технологических процессов с последующей автоматизацией не может быть односторонним.
Успех проекта возможен только в случае активного участия всех заинтересованных сторон, задача Менеджера проекта контролировать и управлять участием Исполнителя и Заказчика в движении к поставленной цели!
Желаю Вам успехов в собственных достижениях! До новых тем!


AshGoale
10.01.2022 16:37:49
WimGoale
10.01.2022 18:23:21
KiaGoale
10.01.2022 19:24:24
WimGoale
10.01.2022 20:47:59
MarkGoale
10.01.2022 21:05:36
AmyGoale
10.01.2022 22:31:43
LisaGoale
11.01.2022 02:08:03