Сегодня процедурная часть управления проектами прописана и технологически оформлена довольно неплохо. Можно не вдаваясь в детали, брать типовые проформы решений, распоряжений, отчетов и иных документов и упаковывать проект требуемыми исходными сведениями: паспорт проекта, устав проекта, бюджет проекта, график проекта, штатное расписание-замещение проекта, структура проекта и т.п. Сюда же иду типовые приказы о создании команды проекта, назначении руководителя, о запуске кабинета проекта в соответствующей информационной платформе документооборота и даже план реализации проекта по отчетным периодам. Всё это касается и строительных проектов, хотя представленные документы вполне могут называться по-другому, в т.ч. в типично бюрократической манере. Даже понимая, что строительные проекты друг для друга - две большие разницы, в одном есть лидер и его личное видение документооборота, в другом - структурное управление и приоритет процедур и процессов, указанные выше документы встречаются так или иначе, пусть иногда и в устной форме.
Пожалуй, единственное, что сильно объединяет проекты разного типа и руководителей проектов разного типа - это всеобъемлющий исторический бардак. К слову надо сказать, иногда этот бардак создаётся искусственно, ибо в нём всегда можно скрыть собственные ошибки и упущения, недочеты и откровенные промахи, и всегда можно отыскать виновного простым манипулированием фактов и обстоятельств. Но, справедливости ради, стоит констатировать, что в большинстве проектов исторический бардак - это естественное состояние. Причины этой естественности банальны до очевидности: это и частая смена руководителей и персонала проекта, это и непредсказуемая динамика проектов в портфеле, когда требуются иные проформы, это и смена контрактных моделей "на ходу" проекта. Одна из неприятных причин - это отсутствие финансирования или адекватного бюджета, когда проект пытаются реализовать минимальными ресурсами, потом всем просто "не до жиру", пусть будет бардак, лишь бы быстрее сдать и отчитаться в срок.
Что, в данном случае. мы понимаем под историческим бардаком? Во-первых, это отсутствие, даже при наличии неплохой системы документооборота и соответствующих приложений по управлению проектами (Битрикс, Директум, Адванта и т.п.), простого и понятного процесса учета фактов и событий проекта. Иногда руководители просят (например, перед соответствующим совещанием с Заказчиками. Инвесторами), составить таймлайн проекта, но отсутствие факта регистрации событий и фактов приводит к тому, что и сам этот отчет становится фальшивым (Таймлайн (от англ. timeline, «временная шкала») - это визуальное отображение последовательности задач, событий или этапов проекта, расположенных на временной оси. Простыми словами, это наглядная цепочка последовательных действий, на которой отмечены ключевые моменты: даты начала и завершения задач, важные вехи, дедлайны, зависимости между работами. Таймлайн представляет собой горизонтальную или вертикальную линию времени, на которой отмечены элементы.). Особенно актуальны подобные инструменты, когда проект длится годами, а персонал меняется как перчатки. Но и эксперты таймлайн-методики говорят, что подготовка таймлайна проекта часто наталкивается на различные сложности, например:
- Отсутствие информации по проекту. Если есть недостаток информации по фактам и событиям проекта, особенно - ключевых вех, просто потому что их никто нигде не фиксировал, то "новички" проекта могут упустить их при подготовке таймлайна. Создание базы или журнала фактов и событий со ссылками на исторический первоисточник поможет избежать ошибок и дезинформации о статусе проекта на поздних стадиях.
- Отсутствие ресурсов доя обработки информации. Менеджеры проектов и даже компаний должны заранее планировать ресурсы по сбору фактов и событий на весь период выполнения проектов, а также предусматривать стыковочное время для подготовки актуальных таймлайнов.
- Оценка актуальности информации. Это одна из самых распространенных сложностей при создании таймлайна проекта. Оценить, какая конкретно информация требуется в какой момент времени - это удел профессионалов, даже если они только подключились к проекту. А поскольку эту работу часто делают случайные ассистенты, то таймлайны или становятся перегруженными ненужной детализацией, или недогруженными важнейшими фактами. Не говоря уже о том, сколько времени потребуется на выполнение задачи, непросто. Для этого приходится учитывать множество факторов: сложность задачи, доступность ресурсов, уровень компетенции команды и другие аспекты.
Логичным решением проблемы отсутствия и оценки важности информации является создания специального журнала сбора фактов и событий. И такой журнал (не путать с обязательными журналами строительных процессов на площадке) должна вести служба поддержки руководителя проекта (ассистенты, диспетчеры, контролеры, администраторы и т.п.) в обязательном порядке и очень дисциплинированно. Именно поэтому мы условно и назвали такой журнал "Судовой журнал проекта" по аналогии с судами и кораблями. В нашем случае, "Судовой журнал проекта" - это обязательный документ, который ведётся регулярно в рамках электронного или бумажного документооборота проекта в течение всего периода его реализации и даже немного больше (например, события по анализу и аудиту после завершения проекта). Журнал должен выполнять несколько ключевых функций:
- Фиксация факто и событий проекта. В журнал вносятся сведения, которые позволяют оценить статус проекта и документы, отражающего его изменения. Например, Совещание о старте проекта со ссылкой на протокол, заключение договора со ссылкой на договор, внесение изменений, решение инвесторов и учредителей и т.п. Обязательно журнал ведется в табличной форме с указанием времени, даты. факта, события, ссылкой на первоисточник, инициатор или связанные лица. При этом, он не должен перегружаться ненужной информацией, всё, что есть в приказах, договорах, протоколах, законах, решениях - дается в виде ссылок, а не дублируется в журнале.
- Документирование работы команды проекта. В журнал фиксируются данные о существенных фактах, генерирующих отклонения от графика и плана реализации проекта, включая решения представителей команды проекта. Например. вместо одной работы начали другие, вместо одного оборудования поставили другое и т.п. Здесь же могут быть решения об остановке работ из-за срыва поставки, из-за климата и внешних условий работы, из-за чрезвычайных событий и происшествий, из-за решений госорганов и т.д.
- Предоставление информации для руководства. Проектный "судовой журнал" должен предоставляться для ознакомления и снятия копий лицам, имеющим право на получение соответствующей информации в соответствии с правилами и положениями о реализации проектов в компании или в государственных структурах. Теоретически, такой журнал должен быть первым документом, который необходим для ознакомления с жизнью проекта и пониманием того, какая информация нужна для решения той или иной задачи и где она находится.
- Обеспечение ответственности за достоверность документов и информации в проекте. Дисциплинарный вопрос проекта не менее важен, чем все вышеупомянутые функции и иные. дело в том, что если каждый сотрудник или руководитель проекта и компании осознает, что сгенерированное им событие или реализованный факт как его решение навсегда остается в журнале, то он невольно начинает ответственно относится к своим обязанностям. Скажем честно, исторический бардак часто и является причиной халатного отношения к проекту и к его печальному результату.
Безусловно, такой т.н. "Судовой журнал проекта" может вестись как на бумажных, так и на электронных носителях, главное, чтобы он имел зеркальное дублирование на разных серверах или облаках, а также имел автоматическое резервное копирование в закрытом от свободного доступа формате. очевидно, что если он ведется в бумажном варианте, то все листы в нём должны быть пронумерованы, прошнурованы и скреплены на последней странице. На титульном листе указываются учётный номер журнала, название проекта, данные о руководителе проекта, даты начала и окончания ведения журнала и иные полезные сведения по усмотрению руководства компании.
Другой важнейшей функцией журнала является рейтингование фактов и событий, а также своеобразный рэнкинг фактов и событий по важности в отчетных периодах. Дело в том, что для составления разных отчетов и таймлайнов может потребоваться разная информация из журнала, как тематически, так и в весовом измерении относительно финансов, экономики и иных политических факторов проекта. Например, допускается, что будет установлен методологический светофор рейтингования фактов и событий. Например, Красное событие помечается специально в программе - это значит, что оно отмечается в любом отчете обязательно. Желтое событие или факт при реализации проекта - это поворотное событие, что-то изменившее в проекте (красное тоже такое, но желтое не всегда критичное). Скажем, было решение о смене подрядчика или проведение новых торгов. Зеленое событие - это событие на решение того, кто готовит отчет. В то же время, рэнкинг событий может показывать, что в отчете важнее все зеленые факты и события т.к. рэнкинг сделан по стоимости и срокам реализации проекта. Важность будет первая по критерию оценки, но не главная по влиянию на реализацию проекта в целом. Это, разумеется, только примеры для самостоятельного методологического инжиниринга такого журнала, но необходимость в нём, как новом документе проектного документооборота - бесспорна.
Статья предлагается впервые, ранее нигде не печаталась!
БИСКИД - Тонкая Настройка Созидания!
Добро пожаловать в НОТЕХ!
Комментарии (0)