Этап инициации обозначает начало нового проекта. На этом этапе организация определяет цели, сферу охвата, ожидаемые результаты, средства и технологии достижения целей, затрат на достижение целей, команду. Часто на данном этапе (в конце) определяют всех заинтересованных лиц и руководителя проекта. Нужно четко понимать, что эти данные приблизительные и чаще всего включают максимальный вариант оценки по всем пунктам.
Вы может быть уже слышали или только узнаете такое понятие как ballpark, это приблизительная оценка, смета с описанием того, что будет реализовано, сколько времени потребуется на это и сколько будет стоить, какие типы специалистов будут задействованы и какие сроки. Как минимум такой документ должен быть на выходе данного этапа.
По-хорошему, основным результатом этого этапа является более подробный документ – устав проекта, который содержит:
– Требования, удовлетворяющие потребности, пожелания и ожидания заказчика, спонсора и других заинтересованных сторон проекта.
– Общее описание проекта или требований к продукту, который является результатом выполнения проекта.
– Цели (по сути, это обоснование проекта).
– Сведения о руководителе проекта, проектной команде (включая роли и обязанности).
– Данные по клиенту, представители клиента и контактные данные.
– Основные этапы проекта.
– Риски и возможные проблемы.
– Список заинтересованных сторон и их участие в проекте.
– Функциональные подразделения организации и их участие в проекте (если есть деление).
– Ограничения, накладываемые организацией, окружением и внешней средой.
– Обоснование проекта, включая бизнес обоснование и данные о ROI (Return on Investment).
– Суммарный бюджет проекта.
Четких требований к данному документу нет. В зависимости от компании и проекта список пунктов может меняться. В приведенном списке выше указано все нужное и важное, устав проекта разрабатывается итерационно и может иметь несколько редакций, постепенно уточняющих, добавляющих или удаляющих пункты.
Данный этап является важнейшим, так как на нем собираются все данные по будущему проекту. Молодые специалисты часто не уделяют ему достаточно внимания и не прорабатывают. Бывает, что и люди с большим опытом часто не делают качественную проработку устава.
Заключительным шагом начального этапа является заполнение формы обзора проекта. Она позволит руководителю проекта эффективно общаться с заказчиками проекта, которые хотят получать регулярные обновления о ходе проекта. Обзоры проектов, как правило, подготавливаются в конце этапов проекта (здесь не говорим про показ функционала, реализуемого в ходе проекте).
На шаге инициации проекта форма обзора проекта будет включать обновления информации о том, запланировано ли завершение проекта и какие сроки, есть ли у организации достаточно ресурсов, а также какие-либо неразрешенные вопросы на данный момент, не позволяющие запустить проект в работу.
Основная цель формы обзора проекта – получить одобрение заказчика, чтобы перейти к следующему этапу.
Основная цель этого этапа – составить детальный план действий.
На нем выделенная на проект команда (да, вы правильно поняли – до этого этапа команда уже должна быть собрана; или как минимум основная часть команды) и руководитель проекта начинают прорабатывать материалы более подробно. План действий представляет собой письменный документ, как и бизнес-план – это «живой» документ, который будет изменяться по мере необходимости в ходе реализации проекта.
К данному плану стоит относится, как к дорожной карте. Он определит масштаб проекта и в нем должны быть перечислены все этапы, чтобы можно было отслеживать любые движения и изменения. План также должен включать информацию о каждой фазе проекта и задачах (без технической или углубленной детализации), над которыми команда будет работать на протяжении всего жизненного цикла проекта. План должен показывать, какие члены команды отвечают за какие задачи, и установить предварительные (максимальные, с учетом возможных проблем, проверок и корректировок) сроки выполнения каждой задачи при первой итерации работы с документом. Далее, в плане должен появиться подробный график проекта от начала до конца. То есть, план может начинаться с нескольких функциональных блоков в начале этапа планирования, но к концу этого этапа он должен превратиться в подробный план, поскольку информация начинает поступать с появлением вопросов при уточнении и детализации плана. Задачей руководителя проекта является ежедневная работа с планом и сравнение его с фактическим статусом задач проектной команды. Для этого удобно использовать одну из систем отслеживания задач, например Jira, Redmine и подобные.
Основной план будет включать в себя несколько подпланов, отражающих конкретные аспекты проекта:
– План ресурсов. Это документ, содержащий важную информацию обо всех ресурсах, которые понадобятся команде, от затрат на рабочую силу до инструментов, чтобы сделать проект успешным. Одним из наиболее важных аспектов плана ресурсов является расписание ресурсов. Этот график позволяет проектной команде планировать, сколько ресурсов им понадобится и для каких частей проекта. В плане ресурсов перечислены типы рабочей силы, необходимые проекту, число ролей, которые необходимо заполнить, и обязанности каждой роли. Он должен также перечислить количество оборудования и других материалов, необходимых проекту для продвижения вперед. Но, это не все, настоятельно рекомендую учесть в этом плане (как минимум):
– праздники,
– отпуски,
– возможные отгулы,
– больничные (вы работаете с людьми, знаете их и сможете спрогнозировать, как часто в месяц они отсутствуют),
– риски (например, задержки у клиента в предоставлении обратной связи),
– занятость на проектах (задействованы на других проектах и на сколько).
Конечно, этот список можно продолжать еще, но я выбрал самое основное и важное. У вас может появится вопрос – зачем так много сложностей? Нет, это не сложности, так только кажется из-за того, что нужно собирать много данных и прорабатывать их. Но это один из важнейших пунктов, данные на выходе которого будут помогать на протяжении всего проекта. Попытаюсь перечислить, что зависит от этого плана:
– прибыль компании от проекта,
– успех проекта (люди работают над проектом),
– своевременный найм сотрудников (а это работа HR),
– подготовка рабочего места (а это работа поддержки),
– эффективность работы компании.
– Финансовый план. Этот план основывается на ресурсном плане и служит для детализации суммы денежных средств, которая потребуется для реализации проекта. Основная цель финансового плана – обеспечить основу для сравнения общего бюджета проекта и его фактической стоимости (сколько потратили на реализацию). Давайте рассмотрим основные пункты финансового плана:
– Административные расходы – оформление юридического лица и налоги, аренда помещения. Рассчитайте, какую сумму вам нужно будет зарезервировать на все бюрократические процедуры и уплату налогов. Данный пункт не обязателен, может быть вы решили начать дело, а компании или помещения еще нет.
– Зарплата сотрудников. Нужно учесть зарплаты всех участников проекта с учетом тех, кого вы еще планируете нанять или тех, кого вы планируете привлекать разово.
– Расходы на закупку материалов или оборудования. На начальном этапе постарайтесь быть аккуратным, иногда сложно спрогнозировать сколько и чего может потребоваться. Зарезервируйте денежные средства с запасом, но закупайте только необходимое. На этом этапе, и пока нет утвержденного ТЗ, стоит уточнять, а нужно ли покупать какой-то софт, библиотеки или специфичное оборудование, т.к. суммы могут быть большими и это может сильно изменить бюджет.
– Транспортные расходы. В этом пункте учтите стоимость доставки материалов к вам, выезды ваших специалистов к клиенту (а это может быть дорого и не один раз, если клиент в другом городе). Определите с какими службами доставки вы будете работать, включите ли вы стоимость доставки в стоимость проекта или же заказчик будет оплачивать ее отдельно. В моей практике были случаи доставки курьерскими службами документов, образцов техники (терминалов), образцов продукции (от пищевой до бытовых средств), поверьте, это было дорого.
– Бюджет на продвижение проекта. В этом пункте обязательно учтите бюджет на разработку фирменного стиля, сайта, упаковку товара, работу фотографа, рекламу в социальных сетях и участие в маркетах (может оказаться, что нужно покупать аккаунты в магазинах приложений).
Не забудьте обсудить с заказчиком его ожидания. Объясните ему, что создание дизайна самого продукта не является фирменным стилем, что его создание является отдельным проектом и на его основе можно будет сделать дизайн ИТ или другого продукта. Уточните, хочет ли клиент индивидуальный дизайн или достаточно использовать что-то готовое, шаблонное (часто клиент не задумывается или имеет свои мысли на этот счет). Это тот минимум, который необходим на старте каждого проекта. Многие руководители проектов не учитывают эти траты при планировании, а зря, они могут составить значительную сумму и время. Подобные расходы возможно просчитать на старте и на ближайший период достаточно точно, далее скорректировать и предупредить об этом клиента. Обязательно нужно заложить 5—10% от общих затрат на непредвиденные расходы. Далеко не всегда все идет по плану, и лучше, если вы будете к этому подготовлены не только морально, но и финансово. Исходя из своего опыта скажу, что дизайн проектов, фирменный стиль, отбор фотографий согласовывается не сразу, то есть это длительный процесс отбора и обсуждений у 80% заказчиков. Не забудьте, что существует такой тип работ, как «Фотосъемки», который стоит прорабатывать и обсуждать отдельно от общей сметы.
– План качества. План позволяет группе оценить качество конкретных достижений в рамках проекта и определить, соответствует ли требованиям выпущенный продукт. Руководитель проекта может использовать план качества, чтобы установить в нем сроки релизов версий для контроля качества и деятельности всей команды, чтобы удержать проект в нужном русле. Руководитель проекта в этом документе продублирует сроки сдачи проекта (финальные) и отметки о смещении сроков и причинах.
– План рисков. Данный план содержит все риски, связанные с проектом. Разбейте их по категориям, а затем по приоритетам, так будет удобнее. Это поможет команде в определении того, какие риски наиболее вероятны и важны, позволив более эффективно распределить время или принять решение об устранении проблемы. В этом плане стоит изложить влияние каждого риска на проект, если не свести к минимуму или не устранить. Группа управления проектом или сам руководитель проекта использует план рисков для разработки и реализации превентивных мер, составления планов действий в чрезвычайных ситуациях и отслеживания каждого риска на протяжении всего срока реализации проекта. План рисков является важным шагом в процессе планирования, так как он может значительно снизить вероятность неудач.
– План приемки служит мостом между результатами работы проектной команды и заказчиком. В плане будет отображено состояние разрабатываемого проекта. Он также нужен, чтобы помочь определить любые ресурсы, которые могут понадобиться для тестирования. В конце концов, это официальное соглашение между заказчиком и исполнителем, в котором будут указаны детали всех результатов проекта и определены стандарты, необходимые для приемки заказчиком. Исполнитель может использовать этот план, чтобы определить, как он будут тестировать выходные данные и функционал проекта.
Правильно будет к данному плану завести документ «Сопроводительное письмо». Используйте его, когда формируете промежуточные сборки для показа клиенту. В файле указывайте списком, что вы планируете показывать и, что может проверять клиент. Напротив каждой задачи стоит оставить поле для комментариев – принята/не принята, замечания для устранения. И не забывайте получить подпись заказчика. Мы все люди, что-то забывается, а согласованный документ напомнит и подтвердит согласованное. Да, это может показаться избыточным – заводить файл, в нем список сдаваемого функционала, подпись клиента и так далее, но вам все равно нужно взаимодействовать с клиентом, а если отправлять через почту, то письмо может потеряться по разным причинам. Если проект мелкий и показов немного, то можно, конечно, коммуницировать через почту. Сопроводительное письмо можно так же использовать на момент сдачи проекта, в нем указать состояние проекта, требуются ли дополнительные работы или нет.
– Плана коммуникации. Его цель – помочь команде передать ключевую информацию нужным людям в нужное время и правильным способом. Коммуникационный план должен включать в себя подробную информацию о проекте в целом со всеми его целями, сроками, стратегиями и задачами. В плане должны быть конкретно указаны все заинтересованные лица и со всех сторон, их роль и индивидуальные коммуникационные требования при указании графика коммуникации. В ходе проекта группа может использовать план коммуникации для сбора отзывов о методах коммуникации.
– План закупок определяет, каким образом группа будет получать ресурсы от внешних поставщиков. Идеальный план закупок должен содержать список всех необходимые ресурсов для закупки. В нем также следует указать, когда и каким образом будут выделены средства для получения этих ресурсов. Группы могут использовать план закупок для изучения необходимых задач и способов эффективного приобретения ресурсов. Этот план не менее важно согласовать с клиентом, чтобы не возникало спорных ситуаций наподобие «Мы думали вы это купите и уже включили в стоимость проекта».
Уточнение:
Все эти планы разделены для удобства восприятия и работы с ними. Но это не значит, что только так нужно разделять. В моей практике были случаи, где это было разбито на пару документов.
– Тендерный процесс. После того, как план закупок будет завершен, следующим шагом является начало процесса подключения к поставщикам услуг и/или оборудования. Команды управления проектами обычно называют это тендерным процессом. Он включает в себя разработку нескольких документов, которые помогут команде управлять закупками и выбрать лучших поставщиков:
– ТЗ определяет и уточняет тип работ, тип поставщика, ресурсы (необходимые команде), график сроков и копию условий оплаты.
– Далее идет документ запроса информации (RFI). Этот документ помогает команде определить потребности.
– После запроса информации запрашивают документ с предложениями (RFP), он поможет команде выбрать лучшего поставщика, опираясь на конкретные предложения.
– Далее идет контракт с поставщиком, который по существу является документом, в котором излагаются условия между организацией и поставщиком. В контракте должны быть конкретно указаны все ресурсы, которые будет предоставлять поставщик, все сроки выполнения и информация о выставлении счетов. В нем также должны быть изложены условия договора для обеих сторон. Эти стороны затем и подпишут документ.
– Наконец, команде потребуются тендерные формы для отслеживания всего, что происходит в процессе выбора поставщиков.
Заключительным блоком работ этапа планирования является еще один обзор проекта. В данном блоке работ в форме обзора проекта следует указать:
– планируется ли завершить проект в срок;
– соответствует ли он бюджету на сегодняшний день;
– устранены или нет какие-либо существующие препятствия и риски.
В нем также необходимо перечислить любые ресурсы и материалы, использование которых было утверждено в процессе планирования.
Более детально планирование будет рассмотрено во второй главе данной книги.
О проекте
О подписке