 |
Как разработать УСТАВ проекта
|
|
|
|
Предпосылки проекта
Начинающие менеджеры проектов в данном разделе обычно описывают предысторию возникновения проекта и то, откуда растут «корни» данного проекта.
Это всё, безусловно, должно присутствовать в этом разделе, но главный вопрос, на который должен отвечать данный раздел – это что произойдет с точки зрения бизнеса, если не будем делать этот проект?
Задав этот вопрос заказчику, вы сразу поймете предпосылки проекта и сможете кратко, но емко их сформулировать.
Предпосылки проекта должны описывать основную проблему заказчика, которую он собирается решить, внедряя данный проект. Т.е. ваша задача в ходе интервью выявить ключевую «боль» заказчика и внести её описание в данный раздел.
Предпосылки проекта по возможности должны быть сформулированы в денежном выражении. То есть в идеале мы должны указать ту сумму денег, которую компания потеряет, если не будет реализовывать ваш проект.
Если вам не удастся с первых секунд захватить внимание Проектного комитета предпосылками проекта, то велика вероятность того, что проект не будет одобрен с первого раза.
Бизнес-цели проекта
Данный раздел должен содержать в себе отSMARTованные формулировки бизнес-целей, ради которых предпринимается ваш проект.
Они должны логичным образом вытекать из предпосылок проекта и указывать на то, насколько данным проектом можно решить ту проблему, ту «боль», обозначенную в предпосылках проекта.
Бизнес-цели должны внятно отвечать на вопрос: зачем с точки зрения бизнеса нужно запускать этот проект.
Так как основной целью любой коммерческой организации является генерация прибыли, то и бизнес-цели проекта должны быть выражены максимально «близко» к деньгам. То есть в терминах дохода и прибыли.
|
|
|
Количество бизнес-целей проекта должно составлять не более трех штук. В противном случае будет трудно понять, а зачем же всё-таки предпринимается данный проект.
Бизнес-модель (business case)
После того, как с заказчиком определены предпосылки и бизнес-цели проекта, необходимо тщательно проработать бизнес-модель будущего проекта.
Бизнес-модель должна четко и внятно отвечать на вопрос: как данным проектом планируется достигать заявленных бизнес-целей.
Иными словами, как с помощью предлагаемого проекта компания заработает и\или сэкономит.
Обычно в данном разделе приводится cost-benefit анализ, который показывает соотношение между расходами и доходами будущего проекта.
Цель данного раздела состоит в том, чтобы продемонстрировать привлекательный для компании ROI.
Если ROI данного проекта будет хотя бы 300-400%, то проект почти наверняка будет запущен. Если ROI меньше 200%, то проект, скорее всего, будет отправлен на доработку или вообще отменен.
Если речь идет о коммерческом «зарабатывающем» проекте, то в данном разделе будет уместно привести воронку продаж будущего проекта, маркетинговый план привлечения клиентов, а также 4P и SWOT-анализ.
Если речь идет об инфраструктурном «экономящем» проекте, то тогда необходимо продемонстрировать сокращение затрат, которое может быть выражено в сокращении времени выполнения операций, сокращении ручного труда, сокращении персонала и прочих показателях.
Ограничения проекта
После того, как определены бизнес-цели проекта и бизнес-модель, необходимо выявить и зафиксировать в уставе те ограничения, которые заказчик и бизнес накладывают на проект.
Как правило, на практике выделяют 3 типа ограничений: по срокам, бюджету и содержанию проекта.
|
|
|
То есть проект может быть ограничен по срокам. Скажем нужно запуститься к такой-то дате. По бюджету, когда заказчик готов выделить на реализацию проекта только какую-то ограниченную сумму. Или по содержанию, когда заказчик хочет, чтобы проект был сделан из каких-то специфических материалов или оборудования.
В качестве примера ограничений проекта по разработке сайта можно привести три ограничения:
1. По срокам – 1 октября 2014 года
2. По бюджету – не более $10 000
3. По содержанию – сайт должен быть сделан только на UMI CMS
Сразу оговоримся, что если в проекте присутствуют все три типа ограничений, то проект будет очень сложно реализовать.
На практике, как правило, бывает одно или максимум два ограничения в одном проекте. Иначе он почти невыполним.
Основные результаты проекта
После того, как определены ограничения проекта, можно переходить к описанию содержания вашего проекта.
В данном разделе необходимо привести основные результаты поставки (deliverables) будущего проекта. То есть, какие результаты будут переданы в итоге заказчику проекта.
В качестве результатов поставки указываются те составные части проекта, которые должна произвести проектная команда.
Для разных типов проектов это будут разные элементы. Скажем, для ИТ-проектов это может быть: разработанное ПО, аппаратное обеспечение, техническая и пользовательская документация, проведенное обучение пользователей и прочие результаты проекта.
Задача менеджера проекта состоит в том, чтобы максимально понятно описать в данном разделе основные результаты, которые получит заказчик по завершении проекта.
Таким образом, в данном разделе указывается всё, что войдет в границы будущего проекта.
Исключения проекта
В отличие от предыдущего раздела, в данном пункте необходимо указать всё, что не войдет в границы проекта.
Иными словами все те результаты, которые не будут произведены в рамках проекта и которые, соответственно, не получит заказчик.
Этот пункт является одним из самых важных в уставе, т.к. четко закрепляет соотношение между ожиданиями заказчика и возможностями проектной команды, исходя из заявленных ограничений проекта.
|
|
|
Проектному менеджеру необходимо «на берегу» договориться с заказчиком о том, что будет произведено в рамках проекта, а что останется за его границами. Это необходимо для того, чтобы на этапе приемки проекта не возникло различного рода недоразумений, которые обязательно возникнут, если пренебречь данным разделом устава.
Базовая оценка по срокам
После того, как выявлены и зафиксированы границы проекта, можно переходить к предварительной оценке сроков проекта.
Как правило, на этапе подготовки устава проекта у проектного менеджера ещё недостаточно информации, чтобы произвести точную оценку по срокам и стоимости.
Поэтому погрешность расчетов на этапе инициации проекта может составлять +-200-300%.
То есть на данном этапе оценка проекта по срокам может быть завышена в 4-6 раз по сравнению с конечной оценкой.
В различных компаниях приняты свои допустимые погрешности на этапе подготовки устава проекта, но в любом случае оценка будет очень примерной с точностью до порядка величины.
На данном этапе достаточно выделить основные этапы проекта, скажем: проектирование, создание прототипа, разработка, тестирование, доработка, пилотная эксплуатация, развертывание и для каждого этапа указать оценочные сроки разработки.
|
|
|
