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

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

 

 

Содержание

 

 

Введение

 

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

Когда речь заходит об определении содержания проекта, команда проекта и клиент как бы меняются ролями. До этого момента с заказчиком в основном контактируют люди, в задачи которых входит «продать» проект. «Продавец» пытался убедить заказчика, что проект — дело стоящее, на него стоит потратиться. Иногда «продавец» описывает проект в столь ярких красках, что намеренно или непроизвольно заставляет клиента поверить: все, что мог себе представить последний в самых невероятных мечтах, благодаря проекту превратится в реальность. На деле такое происходит весьма редко.

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

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

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

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

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

Целью работы является управление содержанием проектов в системе планирования на предприятии.

Для достижения поставленной цели были решены следующие задачи: 

1. Рассмотрены теоретические аспекты изучаемой темы.

2. Разработан план управления содержанием проекта ЗАО «НижЭкоКом».

3. Определена эффективность бизнес-плана как основы инвестиционного проектирования деятельности предприятия.

Предметом данного исследования является проектирование.

Информационной базой данной работы служат: ГК РФ, данные текущей периодики журналы «Экономический журнал ВШЭ», «Свободная мысль», исследования экономистов современников по изучаемой теме Горемыкина В.А., Переверзева М.П., Логвинова С.И., Логвинова С.С. и других.

 

 

 

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

 

1.1 Построение и развитие содержания

 

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

Основной задачей проектной команды далее становится переход от содержания продукта к содержанию проекта, то есть определение всех тех работ, которые необходимо произвести в проекте для удовлетворения требований заказчика по содержанию. [3.C.126]

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

 

Рисунок 1- Блок-схема содержание проекта

 

Не стараясь формализовать процедуры и процессы управления проектами, следует все же отметить ряд документов, которые обычно производятся в ходе разработки содержания проекта. Проект запускается в момент подписания устава (хартии, заявки, приказа) – project charter. [3.C.127]

 

1.2 Project Charter

 

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

Устав (хартию) проекта составляет менеджер проекта, а вот подписывается тем, кто отвечает за создание и финансирование проекта. Было бы бессмысленно, если менеджеры проектов сами создавали и утверждали свои собственные проекты. Однако важно то, что менеджер проекта сам подготавливает данный устав, поскольку это является его первой возможностью определить проект именно так, как он сам его представляет. [3.C.128]

 

1.3 Анализ окружения

 

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

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

Рисунок 2 – Построение матрицы анализа окружения

 

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

Далее, определяются все ключевые заинтересованные участники и их роли:

 

Рисунок 3 – Участники проектирования

 

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

• Менеджер проекта
• Исполнители
• Заказчик
• Спонсор

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

Идеальная ситуация, достижимая в организациях с развитой культурой управления проектами – это когда роли заинтересованных участников, а также их основные обязанности определены на корпоративном уровне. Естественно, в случае отсутствия таких корпоративных документов менеджер проекта вынужден вместе с другими членами команды определять их сам на самых первых этапах проекта. Окончательная цель – не только определить роли и ответственности, но и донести их до тех, кто эти роли в проекте будет исполнять. [5.C.78-80]

Таблица 1 – Типовые роли участников проектов

Менеджер проекта	Лицо, несущее ответственность за результат проекта (выполнение тройного ограничение), управление ресурсами внутри проекта (в целом), коммуникации, отчетность по проекту перед МПП/другими stkh
Менеджер портфеля	Лицо, отвечающее за приоритезацию проектов в портфеле, актуализацию приоритетов, отчетность по портфелю перед топ-менеджментом
Координатор ресурсов в портфеле	Лицо, несущее ответственность за распределение ресурсов между проектами, отчетность перед менеджером портфеля по суммарному статусу проектов
Владелец (менеджер) ресурсов	Лицо, отвечающее за выделение конкретных ресурсов подразделения на проект
Исполнитель/ функц. специалист	Лицо, осуществляющее выполнение конкретных работ/функций в рамках проекта (больше или равно 4 часам в неделю), участвующее в текущих процедурах планирования и отчетности
Заказчик	Лицо, ответственное за инициацию проекта, определение основных объектов поставки (содержания), определение возможности досрочного закрытия проекта (по согласованию со спонсором), приемку продукта, инициацию изменений в содержании
Владелец процесса/ Функциональный заказчик	Лицо, определяющее основные объекты поставки в части своего функционала по проекту, инициирует и согласует изменения содержания в части своего функционала, осуществляет приемку результатов в рамках своего функционала
Согласователь/контролер	Лицо, определяющее соответствие проекта и его продуктов требованиям внешних стандартов

 

 

1.4 Определение успешности проекта

 

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

70 – 80 годы послужили временем  изменения подхода к проектному  управлению. К этому времени относится  использование новых "мягких" (soft) инструментов и подходов, в первую очередь связанных с человеческими ресурсами; следующим шагом стало распространение так называемого системного подхода в проектном менеджменте – подхода, при котором менеджеры проекта начали рассматривать более широкий контекст предприятия и общества в целом, в котором выполняется проект. Применение проектного управления в совершенно новых областях – в том числе при реорганизации предприятий государственной службы и реализации международных социо-экономических проектов – а также его активное использование внутренними ИТ-проектами предприятия кардинально изменило отношение к данной методологии руководителей всех уровней компании, превратив его из простого технического инструмента в средство реализации стратегических решений компании. [7.C.111]

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

Одну из таких методик мы рассматривали ранее в части, посвященной управлению изменениями в компаниях – это методология управления по результатам, или result-based management (см. след. главу).

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

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

Всегда применяются по окончанию проекта.

Обычно находятся под контролем команды проекта,

то показатели успешности продукта:

Могут применяться через длительное время после окончания проекта.

И обычно выходят за рамки прямого контроля проектной команды.

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

 

Рисунок 4 – Влияние факторов на успешность проета

 

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

Возможные примеры соотношения критериев успешности продукта для разных заинтересованных сторон представлены ниже:

Таблица 2 - Соотношение критериев успешности продукта

Заинтересованное лицо	Определяет успешность как…
Контроль качества, ИТ	Соответствие внутренним стандартам качества
ИТ, разработка	Простота в разработке и поддержке
Маркетинг	Рыночная новизна
Фиансы	Проект с низкими затратами
Акционеры	Продукт с высокой "маржой"
Покупатли	Дешевый продукт