5.3.Фазы проекта

5.3.1.Инициация проекта

Инициация проекта – это фаза до начала активных работ над проектом и заключением самого договора на проект – так называемый «предпроект».

В предыдущих главах рассматривались вопросы выбора заказчиком ERP-системы, внутреннего сбора требований к ней, проведения тендера. Это и есть предпроектные работы.

Фаза может быть от очень краткой (неделя) до вялотекущего внутреннего процесса на стороне заказчика (месяцы, полгода, год) – фоновый анализ ERP-систем на рынке, неспешный сбор требований и т. п. В какой-то момент начинается активность, приглашают потенциальных исполнителей, а для них эта фаза «бесплатная», потому затягивать ее им самим резона нет. Хотя если какие-то рассмотрения и согласования требуют времени, то предпроект затягивается, но календарно в днях, а не из-за больших трудозатрат исполнителя на задачи в нем. Затраты в этой фазе несут обе стороны:

• заказчик – на фонд оплаты труда своих сотрудников, возможно, на командировки;
• исполнитель – на привлечение специалистов на экспресс-анализ, отчет по анализу, настройку прототипа для показа, презентации.

Целями фазы являются:

• Установить границы и рамки проекта – достижение понимания среди заинтересованных лиц проекта, что войдет в будущую систему и будет внедрено, а что не войдет.
• Определение участников проекта со стороны заказчика и выбор исполнителя – экспресс-анализ собранных требований и бизнес-задач.
• Заключить договор на работы и начать сам проект.

Документооборот и результаты фазы:

Результат (документ)	Рабочий/отчетный	Ответственный за создание
Приказ о начале работ над проектом	Отчетный	Директор заказчика
Спецификация требований	Рабочий	РП заказчика
RFI/RFP/RFQ	Отчетный	РП заказчика
Соглашение о неразглашении	Отчетный	РП заказчика
Коммерческое предложение	Отчетный	РП исполнителя
Опросники	Рабочий	Консультант
Протоколы совещаний	Рабочий	РП исполнителя
Отчет об экспресс-обследовании	Отчетный	РП исполнителя
Презентации системы и проекта	Рабочий	РП исполнителя, консультант
Устав проекта	Отчетный	РП заказчика (по факту РП исполнителя)
План-график проекта (предварительный)	Отчетный	РП исполнителя
Договор на проект	Отчетный	РП исполнителя

Нужно отметить, что устав проекта, который, по идее (позиция PMBOK), должен делаться на стороне заказчика как первый документ, инициализирующий проект и назначающий руководителя проекта и его участников, по факту не делается вообще либо делается стороной исполнителя, чтобы зафиксировать все регламенты взаимодействия и состав команды (ситуации, когда данный документ не делается совсем, тоже бывают, но это уже не проектная методология, а ее отсутствие). Вместо устава на стороне заказчика проект инициируется приказом по компании о начале работ и выделении полномочий руководителю проекта (или назначении этой роли дополнительно какому-то сотруднику). Приказ может быть в виде электронного письма и формально отчетным (с подписью и печатью) документом не будет, либо вообще устным («давайте с понедельника этим займемся, ты будешь крайним»). Как и что анализировать, оценивать сроки и бюджет проекта, мы рассмотрим в следующих главах. Здесь же остановимся более подробно на уставе проекта. Он крайне важен для инициирования работ, с ним вся команда проекта одинаково понимает инструментарий взаимодействия, регламенты документооборота, цели проекта и критерии их достижения.

Устав проекта содержит разделы:

• История изменений – версии, даты, кто и что менял (устав – «живой» документ и может уточняться итерационно и потом по ходу проекта тоже).
• Назначение документа – для чего это все, показать важность документа.
• Основные понятия и определения – чтобы говорить на одном языке и ввести словарь сокращений и принятых в проекте терминов (особенно терминов заказчика, т. к. на фирмах имеют свой сленг и кучу аббревиатур, совсем непонятных внешнему исполнителю).
• Основания и порядок изменения документа – критерии, когда можно и даже нужно менять документ (например, пересмотр целей и границ проекта в ходе анализа и дизайна).
• Цели проекта – что именно ожидается от проекта внедрения ERP-системы, по пунктам, основные результаты проекта.
• Границы проекта – организационные и функциональные границы проекта, какие подразделения и функциональные блоки системы задействованы в проекте.
• Критерии успешности проекта – список критериев, по которым проект будет оцениваться в конце как выполненный (очень важно иметь понятный критерий завершения проекта, иначе можно попасть в вечный цикл: «А вы нам еще не сделали… и мы не может закрыть вам акт выполненных работ»).
• План-график проекта – может быть отдельным документом, но часто включается в устав (хотя бы высокоуровневый, если отдельно ведется более детальный).
• Основные контрольные точки проекта – таблица событий и ожидаемых дат, когда они должны произойти: подписание документов, завершение фаз, запуск функциональности в работу, получение каких-то результатов от учета в системе и т. п.
• Организационная структура проекта – описание структуры команды проекта (заказчика и исполнителя), управляющего комитета и перечень конкретных специалистов (ФИО, контакты), преемственность, требования к квалификации.
• Подход к выполнению работ – описание проектной методологии, каждой фазы, документооборота по фазам и кто делает (согласует) документы, места и время выполнения работ, инструментарий коммуникаций (для фиксации возможности удаленного взаимодействия и программных средств).
• Риски проекта – список потенциальных рисков и инструментарий управления ими для своевременного выявления и минимизации.
• Проектные процедуры – порядок взаимодействия команды проекта: совещания, протоколирование решений, порядок согласования документов (время согласования на каждый тип документа), порядок планирования отпусков и обучения, управление изменениями, удаленное взаимодействие, управление конфликтами, управление рисками, урегулирование спорных ситуаций.
• Ограничения и допущения проекта – факторы внешней и внутренней среды, влияющие на проект.
• Секция утверждения устава проекта – реквизиты сторон, подписи, печати, как на договоре.
• Приложения – шаблоны проектных документов.

Успешное завершение этой фазы заключается в определении границ проекта и заключении договора на проект внедрения ERP-системы сразу на весь проект, либо только на первый этап, либо только на детальный анализ и концептуальное проектирование. Последнее – это самый удобный для исполнителя и компромиссный для заказчика вариант, позволяющий уточнить границы и бюджет проекта, а не «угадывать» после экспресс-анализа. Заказчику это дает время приглядеться и сработаться со специалистами исполнителя, получить готовые проектные документы этой фазы и принять решение о продолжении (или замене исполнителя) работ на следующих фазах проекта. И, конечно, на этой фазе решаются финансовые вопросы: примерный бюджет проекта, покупка лицензий на систему, график оплаты работ по внедрению. В договоре фиксируется график платежей или формула/критерий для вычисления графика по ходу проекта. Тут возможна вариативность:

• аванс (30–50 %) и постоплата в конце;
• аванс (до 20–30 %) и оплаты по факту выполненных работ (по месячным актам, фазам или иным достижимым критериям);
• иные варианты, компромиссные для сторон проекта.

После всех работ по фазе и принятии решений о начале работ, подписания договора уместно провести совместный тимбилдинг команды проекта или иное мероприятие для налаживания более тесных контактов между ключевыми сотрудниками заказчика и специалистами исполнителя.

Отправить