Содержание проекта пример

Пример описания проекта: содержание, цели и особенности

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

Сущность проекта

Суть проекта: предоставление услуг по организации тематических вечеринок ИП «Машина времени». Преимуществом проекта в сравнении с конкурентами является многообразие и уникальность предоставляемых услуг, узкая специализация. Стоимость реализации бизнес-плана составляет 127 112 руб. Финансирование проекта входит в описание бизнес проекта. Пример – полное финансовое обеспечение собственными средствами. Проект благоприятно сказывается на вопросе безработицы. Так как его введение создаст 5 рабочих мест.

Анализ рынка

• Анализ положения дел в отрасли.

Рынок, на котором планирует работать предприятие – локальный. В регионе функционируют около двухсот средних и крупных компаний, принадлежащих к разным сферам деятельности. По данным Территориального органа Федеральной службы государственной статистики по Брянской области получается, что в 2011 году рождаемость составила 9227, а в 2012 г. — 9410 человек, что предполагает увеличение численности потенциальных клиентов. Помимо этого, статистические данные указывают на рост среднемесячной заработной платы жителей Брянска. Если в 2011 году она составляла 13912 руб., то в 2012 году ее значение достигло 16530 руб. Что позволяет говорить об улучшении жизни жителей региона.

Описание инновационного проекта, пример которого рассматривается в конкретной ситуации, должно содержать информацию о емкости рынка. Емкость рынка по корпоративным вечеринкам составляет примерно 24 млн. руб. Это связано с тем, что в Брянске около 200 компаний потенциально могут стать клиентами фирмы.

Подразумевается, что каждая из них устраивает корпоративную вечеринку 3 раза в год. На каждое из этих мероприятий у компании уходит в среднем 40 тыс. руб. Что касается тематических вечеринок в честь дня рождения, то по ним емкость составляет 4 108 370 тыс. руб. При этом учитывается численность населения Брянска, насчитывающая 410 837 человек. В среднем каждый из них тратит на празднование дня рождения 10 тыс. руб. Ожидаемая доля рынка, которую фирма планирует захватить — 5%. В связи с функционированием на ней большого числа праздничных агентств, данный процент будет достаточно весомым и прибыльным.

• Варианты стратегического поведения с целью снижения степени угрозы для бизнеса со стороны конкурентов.

Рассматривая конкурентные стратегии М. Портера, следует отметить, что «Машина времени» избирает стратегию концентрации. То есть компания принимает решение конкурировать только в узком сегменте рынка, а именно заниматься проведением только тематических вечеринок. Из конкурентных стратегий Ф. Котлера, фирме подходит стратегия нишевика, так как компания специализируется на обслуживании только тех клиентов, которые желают устроить тематическую вечеринку.

• Характеристика потенциальных конкурентов и потенциальных угроз для бизнеса.

В Брянске около 50 праздничных агентств, но ни одно из них не включает в перечень базовых услуг проведение тематических вечеринок. Данная услуга либо рассматривается как дополнительная, либо и вовсе не предлагается клиентам. Основным рыночным сегментом для данного предприятия выступают корпоративные и частные клиенты.

План сбыта и маркетинга

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

Цена на услуги агентства будет рассчитываться на основании комбинированного метода ценообразования, то есть будут использоваться затратный и рыночный методы. Система сбыта — с указанием фирм, привлекаемых к реализации услуги. Для реализации проекта потребуется помощь кафе и ресторанов Брянска, школы танцев «Шаг вперед».

Ожидается, что в феврале, марте и декабре поступит наибольшее количество заказов, так как в этот период предприятия устраивают корпоративы.

План производства

Потребность в основных средствах также должна входить в пример описания проекта. Для запуска праздничного агентства «Машина времени» понадобится помещение, МФУ, сотовый телефон, проектор, офисный диван, шкаф. Помещение будет предоставляться на условиях аренды. МФУ Panasonic KX-MB и Проектор Nec V260 приобретаются в магазине «Позитроника», сотовый телефон Explay TV240 White покупается в магазине DNC, а офисный диван и шкаф — в магазине «Аланта».

Финансовый план

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

Дата его запуска планируется на 1.01.17 года. Расчет амортизации проводится из допущения, что оборудование амортизируется за 5-10 лет, в зависимости от его технического состояния.

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

Не стоит упускать описание рисков проекта. Пример требует для рассмотрения ситуации роста инфляции, кредиторской задолженности, длительность срока окупаемости.

Выводы

Рассматриваемый проект предусматривает открытие агентства по организации тематических вечеринок «Машина времени». Валовой объем продаж на последний год осуществления проекта должен составить около 7 миллионов рублей.

Инициатор проекта обладает значительным опытом работы в рассматриваемой сфере, что будет способствовать эффективной организации производства. В целом, проект оценивается как перспективный, обладающей рыночной, технологической и экономической привлекательностью.

Содержание проекта пример

Содержание проект а – описание работ, которые необходимо выполнить, чтобы получить продукт.

Для описания ВСЕХ необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится.

На языке нашей методологии данные шаги звучат следующим образом:

1. Собрать и финализировать требования
2. Сформировать концепцию
3. Создать ИСР (WBS)

Вернувшись к схеме в предыдущей главе вы можете заметить, что формирование концепции и создание ИСР (WBS) разделены еще двумя шагами из других областей знаний. В настоящей главе мы будем говорить о первых двух этапах со

здания содержания проекта (без ИСР).

Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: выявление заинтересованных лиц и собственно сбор требований. Об этом подробнее мы поговорим ниже.

Сбор требований

Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе (вполне возможно, что они описаны несколькими предложениями). Наша задача конкретизировать их.

Чтобы справиться с ней – необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.

Крайне опасно на данном этапе поддаться искушению «назначить» ответственным за все требовани

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

Лучшие проектные практики гласят:

• проект с неудовлетворенными ожиданиями заказчика не является успешным
• проект, результаты которого не используются конечными пользователями, не является успешным

Помните об этих двух тезисах. Сейчас вам предстоит одна из самых изнурительных задач в проектном управлении – выявлять заинтересованных лиц и собирать требования. Это не забота заказчика, это ваша забота. Пренебрегая ей – вы рискуете в лучшем случае «закрыть контракт формально, испортив отношения с заказчиком», а в худшем – п

олучить на исходе проекта лавину претензий и придирок, которая утопит и вас и команду и сделает сдачу невозможной.

Выявляем заинтересованных лиц

Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц». Пример такого документа приведен в Приложении 2.

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу мы

называем того или иного человека «заинтересованным лицом»?

Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).

Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае не пренебрегайте их интересами в проекте!).

В третьих, не забывайте о боссах членов вашей команды.

В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.

Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако по

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

Не бойтесь включать в реестр большое количество людей. Вы всегда сможете классифицировать их по «степени влияния на проект» позднее и работать тол

ько с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).

Готовимся к сбору требований

По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.

Введем два термина: «требование» и «ожидание».

Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департа

мента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.

Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».

Нам предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований (разумеется, нас в меньшей степени волнует наша собственная команда, и куда больше – представители заказчика и всевозможные стоящие за ним и над ним «серые кардиналы»).

Выбирая методы, необходи

мо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

• Интервью
• Опросники
• Мозговые штурмы (в различных вариациях)
• Прототипирование

Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосред

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

Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к

заполнению анкет (по принципу «чтобы отстали»).

Мозговой штурм – весьма условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Однако помните, что некоторым людям трудно общаться даже в небольших коллективах – чтобы они не «отмалчивались» и не стеснялись в высказываниях, развивайте навыки ведения подобных мероприятий.

Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для проду

К сбору требований мы приступаем, определившись с методами и вооружившись реестром заинтересованных лиц.

Сбор требований ПМ ведет не в одиночку, а совместно с командой. Собственно команда окончательно будет сформирована чуть позже, но на данном этапе нам уже пригодятся помощники (надеюсь, вы добавили соответствующую за

пись в устав и заблаговременно предупредили «хозяина ресурсов» о ваших потребностях).

Если в вашей компании есть специалисты по сбору и описанию требований (например, аналитики), тогда львиную долю забот в этой области можно переложить на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».

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

ребований – мог бы его просмотреть и дополнить.

Прежде чем отправиться к заинтересованным лицам (или отправить туда коллектив аналитиков) – определитесь, как будут храниться собранные требования. Совершенно не обязательно после каждого интервью или мозгового штурма рисовать схемы в определенной нотации. Если вы считаете, что достаточно будет текстовых описаний и произвольных картинок «от руки» – возможно, вы правы. Главное, договоритесь заранее, как будете фиксировать собранные требования со всеми участниками процесса.

После того, как процесс запущен, и требования стали поступать – не забывайте фиксировать их. Возможно, у вас на столе начинает расти пачка «организационных диаграмм», или электронная почта ежедневно пополняется по

Однако вам, как проектному менеджеру , важно сохранить контроль над процессом в целом, иметь возможность планировать и отслеживать выполнение работ для всего многообразия пожеланий заказчика. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3. дробными «отчетами об обследовании» и «отчетами об интервью». Все они окажутся весьма полезны в дальнейшем – при выполнении работ, при необходимости уточнить задачу.

Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал) , насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.

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

Когда остановиться? Проектные практики призывают нас собрать все требования, которые могут относиться к нашему проекту и только после этого двигаться дальше. Помните – «что нельзя спланировать, то нельзя и сделать».

Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.

Сбор требований в рамках начального планирования должен быть разумно-глубоки м и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта – основа проектного управления.

Иногда процесс первоначального сбора требований оказывается столько трудоемким и растянутым во времени, что целесообразно выделить его в отдельный проект. Если предполагаете большие трудозатраты – обсудите это со спонсором как можно раньше.

ОСНОВНЫЕ ПОНЯТИЯ И СОДЕРЖАНИЕ ПРОЕКТА

1.1 Основные признаки и характеристики проекта

Современное общество – это общество, в котором постоянно реализуются самые разнообразные проекты в различных областях – образовании, науке, строительстве, производстве, законотворчестве и т.д.

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

Независимо от предметной области, отличительными признаками проекта являются:

· направленность на достижение конкретных целей, определенных результатов. Проект не может существовать без цели. Ее достижение определяет завершение проекта;

· наличие изменений. Осуществление проекта всегда несет изменения предметной области, в которой он реализуется;

· координированное выполнение многочисленных, взаимосвязанных действий;

· ограниченная протяженность во времени, с определенным началом и концом. Для каждого проекта определяется время его начала и завершения и тем самым ограничивается его продолжительность;

· неповторимость. Неповторимость относится не к отдельным составляющим проекта, а к проекту в целом. Отдельные работы в рамках проекта могут быть такими же, как в других проектах, но их сочетание в рамках данного проекта является уникальным;

· ограниченность требуемых ресурсов. Объем выделяемых на проект ресурсов всегда конечен, поскольку ограничивается его бюджетом и тесно связан со сроками и продолжительностью проекта;

· комплексность и разграничение. В каждом проекте в комплексе учитываются все внутренние и внешние факторы, влияющие на его результаты. При этом проект имеет четко определенные границы, отделяющие его от других проектов;

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

Существует ряд определений термина «проект», каждое их которых имеет право на существование, в зависимости от конкретной задачи и учитывающие перечисленные отличительные признаки.

В самом общем виде проект (англ. project) – это «что-либо, что задумывается или планируется, например большое предприятие» (толковый словарь Webster).

С точки зрения системного подхода, проект может рассматриваться как процесс перехода из исходного в конечное состояние (результат) при участии ряда ограничений и механизмов (рис. 3).

В «Кодексе знаний об управлении проектами»[2] проект – некоторая задача с определенными исходными данными и требуемыми результатами (целями), обуславливающими способ ее решения. Проект включает в себя замысел (проблему), средства его реализации (решения проблемы) и получаемые в процессе реализации результаты (рис. 4).

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

Планирование проекта

План управления проектом

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

План управления проектом может быть либо резюмирующим, либо детализированным и состоять из одного или нескольких вспомогательных планов и прочих элементов.

План управления проектом рекомендуется разделять на 3 блока по характеру содержащейся в них информации.

1. Вспомогательные планы управления проектом, в число которых входят:
   • план управления содержанием проекта;
   • план управления расписанием проекта;
   • план управления стоимостью проекта;
   • план управления качеством проекта;
   • план управления обеспечением персоналом;
   • план управления коммуникациями проекта;
   • план управления рисками проекта;
   • план управления конфигурацией.

Рассмотрению основных вспомогательных планов управления и элементов базовой линии проекта, равно как и описанию ключевых методов и процедур составления этих планов, посвящены отдельные разделы данной книги.

Формирование иерархической структуры проекта

Иерархическая структура работ ( ИСР ) — это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта . Работы, не включенные в ИСР , находятся за пределами содержания проекта [18].

Модель может быть выполнена графически, в виде древовидной структуры или в виде словесного описания. С ее помощью структурируется и определяется все содержание проекта .

Построение ИСР

Существуют два основных способа разработки ИСР : «сверху вниз» и «снизу вверх». Далее приводится описание подхода «сверху вниз».

1. Сбор исходной информации.

Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:

• требования заказчика;
• пул доступных ресурсов;
• конкретная проектная ситуация.

После получения необходимой информации о факторах, влияющих на структуру ИСР , необходимо определиться с типом построения ИСР : по жизненному циклу, по системам, по географическим зонам.

В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта . Хороший пример использования такого типа структурирования ИСР — проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР . Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т. д. Что касается следующих уровней ИСР , многие специалисты практикуют гибридные ИСР , сочетающие два или три метода.

При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту, это позволит избежать сопротивления новому методу, которое неизбежно возникнет.

Принимая во внимание тот факт, что число пакетов влияет на время и стоимость управления проектом, нужно выбрать такое количество пакетов работ, для управления которыми есть время и бюджет. Вообще говоря, пакетом работ мы будем называть основной элемент управления ИСР , дискретную задачу, имеющую определимые конечные результаты, за достижение которых отвечают организационные единицы. Очевидно, пакеты работ должны представлять небольшие результаты и быть управляемыми.

Для определения степени детализации ИСР нужна следующая информация:

• количество уровней в ИСР ;
• количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны

ИСР со следующей детализацией:

• от трех до четырех уровней;
• от 15 до 40 пакетов работ;
• от 40 до 80 часов на средний пакет работ;
• от 3% до 7% общего бюджета рабочих часов на средний пакет работ [18].

Несмотря на уникальность каждого проекта, ИСР предыдущего проекта часто может служить шаблоном для нового. Например, большая часть проектов внедрения ИС в конкретной организации будет иметь одинаковые жизненные циклы, а потому и одинаковые или схожие результаты каждой фазы. Шаблон ИСР представляет собой древовидную структуру работ, детализированную до уровня пакетов работ, которую можно адаптировать под конкретные проекты в конкретной области приложения.

Определение содержания проекта

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

Описание содержания должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта — он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.

Автором данного документа является назначенный уставом проекта руководитель проекта , следовательно, данный документ пишется с позиции исполнителя проекта.

К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:

• устав проекта ;
• формулировка требований организации-заказчика;
• ТЭО ;
• внутрикорпоративная методология управления проектами и соответствующие политики.

В табл. 2.1 приведены требования к описанию содержания проекта: перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению. Аналогично уставу проекта для поддержания версионности разрабатываемого документа и отслеживания его статуса рекомендуется использовать лист управления документом, шаблон которого был приведен в разделе об уставе проекта.

Управление содержанием проекта

Содержание проекта – это то, что проект включает в себя, и в чем он состоит. Управление содержанием проекта – достаточно большая область знаний, владея которыми Руководитель проекта определяет, что входит в проект и что остается за его рамками.

Содержание проекта – это наличие в проекте тех работ, которые необходимо выполнить, для того, чтобы получить желаемый результат.

Таким образом, содержанием нужно управлять и контролировать его на протяжении всего жизненного цикла проекта, следить за тем, чтобы в списке необходимых работ не появились лишние, не относящиеся к желаемому результату проекта. Или какие-то побочные, относящиеся уже к другому проекту.

Также стоит различать содержание проекта и содержание продукта: в первом случае, это работы, которые необходимо выполнить для получения желаемого результата (продукта, услуги), во втором случае – это функции и характеристики результата.

В процессе определения содержания появляется детальный документ, в котором отражены цели и задачи проектных работ.

Не стоит так же забывать, что для достижения одного результата могут быть использованы различные альтернативные методы, таким образом, следует рассматривать вопрос шире, со всех сторон, чтобы не упустить более выгодные возможности.

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

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

Чем детальнее и однозначнее звучат пункты содержания проекта, тем проще потом определить, что проект завершен, то есть выполнены все требования и достигнуты все поставленные цели.

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

Содержание проекта включает в себя:

• Описание содержания проекта;
• Критерии приемки результата;
• Границы проекта (что входит в проект и что нет);
• Ограничения проекта;
• Допущения проекта.

Об описании содержания проекта, критериях приемки результата и границах проекта поговорим ниже.

Описание содержания проекта

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

1. Сама система (тут же приводится список ее компонентов).
2. Права в системе, настроенные в соответствии с утвержденным бизнес-процессом.
3. Техническое обеспечение системы (сервера, подключение на машины пользователей).
4. Комплект документации (тут перечень) для поддержки и развития решения.
5. Обученные пользователи.
6. Обученные специалисты службы поддержки, которые все это добро будут поддерживать.
7. Обновленные нормативные документы компании (например, процедура по работе с дебиторами).

Критерии приемки результата проекта

По каждому из элементов содержания проекта, приведенному выше, указывается, как заказчик и мы сами поймем, что результат действительно соответствует ожиданиям? Это обычно самая сложная часть описания содержания проекта, т.к. степень неопределенности еще слишком высока, а договариваться нужно уже тут, на берегу,пока работы не начались.

Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.

Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.

Границы проекта

Помимо того, что команда проекта будет делать в ходе его реализации, очень важно определить, чего она делать не будет.

На рисунке ниже схематично изображено определение границ проекта.

Определение границ проекта

В ходе описания границ проекта определяются и документируются все моменты, которые могут подразумеваться как часть проекта, но таковой не являются (опять же, в идеально случае вы просто детализируете то, что ранее написали в уставе проекта).

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

Управление содержанием целесообразно еще и потому, что позволяет контролировать объем усилий и средств, направленных на получение результата. Что, если на выполнение проекта потрачено огромное количество ресурсов, усилий, времени – а результат, мягко говоря, того не стоит?

Хорошо написанное содержание проекта – одна из основополагающих успеха проекта и отличный инструмент коммуникации, который руководитель проекта должен уметь использовать во благо этого проекта.

Источники:

http://businessman.ru/new-primer-opisaniya-proekta-soderzhanie-celi-i-osobennosti.html
http://www.sites.google.com/site/infodambueva/obespecenie-proektnoj-deatelnosti/sablony-formy-standarty-soderzania-proekta
http://studopedia.ru/4_88263_osnovnie-ponyatiya-i-soderzhanie-proekta.html
http://www.intuit.ru/studies/courses/646/502/lecture/11392
http://upravlenie-proektami.ru/upravlenie-soderzhaniem-proekta-granitcy-i-dopushcheniia-proekta