Организационная структура работ проекта

Цели и результаты проекта

Второй вопрос системного анализа для решения проблемы: «Для чего необходимо решение проблемы?»

Итак, необходимо определить цели и результаты проекта.

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

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

Результат проекта формулируется в виде цели.

Сформулированная цель – это то, чего мы хотим достичь.

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

С течением времени из-за изменения объективных или субъективных факторов существует опасность изменения цели не только по форме, но и по сути. Поэтому

Установить правильную цель важнее, чем найти наилучший способ ее достижения;

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

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

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

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

Жизненный цикл

Для эффективного управления проект должен быть хорошо структурирован. Суть структуризации или декомпозициии сводится к разбивке проекта на:

фазы жизненного цикла проекта, этапы, работы, задачи;

организационную структуру исполнителей по проекту;

структуру распределения ответственности;

общие системные функции, выполняемые на всех фазах реализации проекта.

отдельные пакеты работ, увязанные между собой в структуру работ по проекту;

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

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

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

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

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

Иерархическая структура работ проекта

Третий вопрос системного анализа для решения проблемы: «Что необходимо сделать для решения проблемы?»

Ответом на этот вопрос служит создание перечня работ, которые необходимо выполнить по проекту. Этот перечень работ носит название иерархической структуры работ проекта (Work Breakdown Structure).

Структура работ проекта – иерархическая структура, разделяющая работы проекта на группы, подгруппы, фазы и т.д.(называется WBS – структура проекта).

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

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

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

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

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

Для выполнения этих действий существуют специальные программные продукты, например Microsoft Project.

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

Организационная структура работ проекта

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

Формируется на основании созданной WBSструктуры.

Выделяют следующие принципиальные организационные формы:

функциональная структура , предполагающая использованеи существующей функциональной иерархической структуры организации;

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

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

Какие ресурсы потребуются?

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

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

Остановимся подробнее на оценке ресурсов.

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

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

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

Будем ли привлекать подрядчиков?

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

Некоторые из «лучших проектных практик» рекомендуют такой подход:

Обязательно использовать субподряды:

Если это снижает риски проекта

Можно использовать субподряды:

Если мы бережем (читай «испытываем дефицит») собственных ресурсов

Если мы пытаемся повысить управляемость проекта

Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.

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

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

«Выбиваем» ресурсы

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

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

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

Построение конструктивных взаимоотношений с «хозяином ресурсов» очень важно. Для этого:

Не требуйте ресурсов «в последний момент». Всегда уведомляйте «хозяев ресурсов» о ваших потребностях как можно раньше (а для этого правильно ведите планирование)

Просите «достаточно хорошие ресурсы». Не настаивайте на выделение к вам в команду «сверхкомпетента» без реальной необходимости.

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

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

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

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

Фамилию и имя сотрудника (избегайте указывать только должность)

Период и объем занятости (например, «доступен с 1 сентября по 31 декабря 2010 года, занятость – 50%» – если речь идет о привлечении сотрудника, который будет делить время между вашим и другим проектом).

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

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

Выходы:

Решение «что покупаем» (устно или письменно)

Список ресурсов

Не нашли, что искали? Воспользуйтесь поиском по сайту: