Наиболее распространенные варианты ответов:
Формальным выполнение фазы подготовки проекта можно считать в том случае, когда результаты этой фазы оказываются невостребованными на последующих этапах работ. План проекта, его организационная структура, процедуры управления, стандарты проекта должны быть рабочими инструментами администрирования проекта, а не мертвыми документами.
Следствиями плохой подготовки проекта могут являться увеличение сроков за счет простоев из-за несогласованности работ, за счет возникновения непредвиденных проблем, потеря времени из-за медлительности в принятии ключевых проектных решений и неприятие проекта организацией вследствие плохой информированности заинтересованных сторон. По-моему мнению, плохая организация проекта стоит на втором месте в списке фатальных причин, приводящих к краху проекта (на первое место я бы поставил непонимание сути проекта внедрения SAP R/3, как такового - об этом читайте в материале "А был ли мальчик? ...").
Стандарты и процедуры проекта следует объединить в "Руководство Проекта" (Project Handbook) - проектный документ, где кратко, но исчерпывающе и доступно сформулированы принципы администрирования проекта.
Однако, объем проекта необходимо уточнить и утвердить на Управляющем Совете в первую очередь, так как это является фундаментальным решением, определяющим весь дальнейший ход проекта.
Формат и структура объема являются индивидуальными для каждого проекта. Можно говорить о функциональном, географическом, юридическом аспектах. В большинстве случаев корректно говорить о внедрении определенных модулей, а иногда это не так, - потому что реализация некоторых сценариев в системе требует подключения функций нескольких модулей.
Тем не менее, после утверждения объема проекта любые его изменения являются предметом для администрирования. Изменения объема влекут за собой изменение бюджета, организационной структуры проекта, технических требований к системе и т. д. Поэтому необходимо создать процедуру инициации, оценки, и утверждения изменений объема, а также процедуру внесения изменений во все подчиненные проектные решения.
Другой, не менее важной проблемой управления проектом внедрения является администрирование выработки и утверждения проектных решений. Отсутствие такой процедуры, особенно на фазе концептуального проектирования, может быть весьма критичным. Постараюсь осветить суть вопроса подробнее.
Значительная часть проектного времени тратится на совещания проектных групп. На таких совещаниях выдвигаются, оцениваются и принимаются разнообразные проектные решения. При этом техника проведения совещаний зачастую оставляет желать лучшего. Предмет совещания заранее четко не определен, по ходу совещания его тема меняется, никаких решений не принимается, принятые решения не доводятся до других участников проекта - все это можно наблюдать достаточно часто. В итоге - до 70 - 80% проектного времени может тратиться непродуктивно.
Простой механизм управления проведением совещаний с использованием повестки и протокола может существенно рационализировать ситуацию. Протоколы совещаний должны быть составлены по возможности проще, но емко и лаконично и быть доступными всем заинтересованным сторонам.
Пул проектных решений является базисом для формирования результирующих проектных документов, таких как требования к системе, технические задания, концептуальный проект и др. (Отметим, что состав и структура этих документов являются темой для отдельного обсуждения). Результаты разного "калибра" должны утверждаться соответствующими органами проектного управления. Рекомендуется к каждому документу прилагать пояснительное письмо, в котором изложены ключевые моменты и принципы.
Таким образом, техника проведения совещаний, порядок регистрации и обобщения решений, формирования соответствующих результирующих документов и регламент утверждения проектных результатов являются предметом процедуры управления проектными решениями.
Далее, я бы отдельно выделил проблему проектного маркетинга, или PR. Особенно это актуально для больших предприятий и распределенных проектов, например - в холдингах.
Суть проблемы состоит в том, что зачастую ключевые лица предприятия недостаточно информированы о ходе проекта и принимаемых решениях и, следовательно, не могут оказывать соответствующую поддержку. Например, проект ведется под эгидой финансово-экономической службы и при этом не учитываются интересы производственников, управление проектом ведется из штаб-квартиры компании, а руководители дочерних подразделений не имеют представления о планах, задачах и степени необходимого участия в проекте. Типичным является недостаточное информирование заинтересованных бизнес-единиц корпорации при ведении "шаблонных" (roll-out) проектов, особенно в мультинациональных концернах.
Отдельно следует отметить проблему недостаточного и несвоевременного информирования партнеров по внедрению - консультантов по проекту и проектных аудиторов.
Такая ситуация приводит к ряду негативных последствий: неожиданно "вскрываются" новые обстоятельства, приходится пересматривать проектные решения, некоторые мероприятия не воспринимаются как адекватные целям проекта - и, следовательно, встречают противодействие.
Методами эффективной информационной поддержки проекта могут являться информационный листок, корпоративная рассылка или интранет и другие. Перечень подобных методов и процедур зависит от корпоративной культуры предприятия и должен формироваться индивидуально на фазе подготовки.
Наконец, закончить этот далеко неполный перечень объектов администрирования в проекте внедрения системы R/3 я бы хотел темой управления прогрессом и проблемами проекта. Эта процедура достаточно хорошо поддерживается средствами ASAP (Issues Database) и состоит в следующем:
В теории положения администрирования прогресса и проблем проекта достаточно понятны. На практике, к сожалению, данная процедура зачастую не работает, что отчасти связано с недостатком навыков проектного управления у менеджеров, а отчасти - с недостаточным вниманием к этому вопросу на фазе подготовки проекта.
Copyright 2001 sappers.narod.ru