Управление проектами - Центр дистанционного обучения

Управление проектами
1. Что такое проект
2. Инициирование проекта
3. Планирование проекта
4. Выполнение работ и общий контроль
5. Закрытие проекта
1. Что такое проект
1. Что такое проект?
2. Что такое управление проектами?
3. Заинтересованные стороны
4. Кто такой менеджер проектов?
5. Организационные структуры
и роль менеджера проектов в них
6. Составные стадии/процессы проекта
7. Жизненный цикл проекта
8. Выбор и приоритезация проектов
1. Что такое проект?
Проект – это временное предприятие, предназначенное для создания уникальных
продуктов, услуг, или результатов. Для проекта характерны следующие черты.
Временность проекта
Любой проект имеет четко обозначенное начало и окончание. Проект заканчивается,
когда:
а. Цели проекта достигнуты
б. Становится ясно, что цели проекта не будут или не могут быть достигнуты
в. Необходимость в проекте или в его целях исчезла.
Слово "временный", однако же, далеко не всегда употребимо по отношению к продукту,
созданному в результате проекта: например, в том случае, когда достигнутая цель
проекта – создание монумента в центре города.
Уникальность продуктов, услуг и результатов
Результаты, полученные по окончании проекта, являются уникальными: даже если
результатом проекта является, например, типовой дом – он все равно будет уникальным,
так как будет отличаться от других домов местоположением, а также, возможно,
владельцем, элементами дизайна, организацией – застройщиком, и т.д.
Уникальность является, пожалуй, одним из главных отличительных черт проекта. К
сожалению, далеко не все осознают, что каждый проект уникален не только своим
содержанием, но и формой, способами достижения желаемых результатов. Применение
одинаковых подходов к каждому проекту ведет к неадекватной оценке его рисков,
ошибочным прогнозам и, в конечном счете, неудовлетворенности клиента. Конечно,
между проектами есть много сходных черт, но каждый из них уникален по своим
свойствам и особенностям развития.
Сходства и различия проектов
Результаты проектов можно разделить на три группы:
Продукт или производимое изделие, являющееся конечным в производственной
цепочке (например, автомобиль), или элементом другого изделия (например,
комплектующее автомобиля).
 Возможность или способность предоставления услуги (например, химчистка под
ключ) или новая программа кредитования в банке
 Результаты исследований – например, результаты изучения общественных
процессов, и т.д.

Последовательная разработка
Третьим свойством, присущим всем проектам, является "последовательная разработка",
т.е. поэтапное и пошаговое развитие. Так, на ранних стадиях проекта его содержание
формируется в общих чертах, а уже в дальнейшем детализируется и конкретизируется по
мере того, как приходит осознание ключевых целей проекта и способов их достижения.
Не стоит путать последовательную разработку с другим свойством проекта – сдвигом
содержания, что означает процесс неконтролируемых изменений содержания проекта.
Последовательную разработку спецификаций проекта необходимо четко соотносить с
правильным определением содержания проекта, особенно если он выполняется по
контракту.
Уровень сложности задач проекта
Кроме того, немаловажной характеристикой проекта является уровень сложности
выполняемых задач. Это отличает его от ежедневной операционной деятельности.
Управление проектом подразумевает больше внимания к вопросам планирования,
применения различных подходов к решению проблем, что объясняется временными
рамками и уникальной природой проекта.
В то же время, необходимо отметить, что между операционной деятельностью и
проектом есть ряд общих черт:
Выполняются людьми
 Ограничены доступностью ресурсов
Планируются, исполняются и управляются.


Среди различий можно выделить следующие черты.
Операционная деятельность
Проект
1. Непрерывный процесс
2. Повторяющаяся деятельность, направленная на
обеспечение нормального течения бизнеса и
зачастую требующая выполнения одних и тех же
действий
3. Невысокая степень риска
1. Временный процесс
2. Деятельность, направленная на
достижение уникальных целей и требующая
выполнения различных нестандартных
действий
3. Деятельность, влекущая за собой высокие
риски при принятии решений
Некоторые виды деятельности не могут управляться проектом. Например, в работе с
клиентом, обновлении информации о клиенте отсутствуют элементы новизны. Напротив,
в ходе установки новой телефонной системы в центре приема звонков может быть
использована методика управления проектами.
Процесс производства товаров, а также предоставление технической поддержки не могут
быть отнесены к проектной деятельности.
Что касается разработки нового продукта, предназначенного для массового
использования, то подобную деятельность можно рассматривать уникальной, и здесь
вполне уместна методика проектного управления.
Следует отметить, что определение стандартных операционных процедур по управлению
текущей деятельностью не редко проводят в рамках проекта.
Одно из ключевых назначений проекта, реализуемого в организации – осуществление
операций, которые не могут быть проведены в рамках ее обычной деятельности. Таким
образом, проект зачастую является средством выполнения стратегического плана
организации, при этом) команда проекта может состоять как из сотрудников
организации, так и нанята по контракту.
Как правило, проекты утверждаются в результате принятия одного или нескольких
стратегических решений, ориентированных на:
Требования рынка
Нужды организации
Требования заказчика
 Технологический прогресс
 Требования законодательства



2. Что такое управление проектами?
Управление проектами – это приложение знаний, навыков, инструментов и методов к
операциям проекта для удовлетворения требований, предъявляемых к проекту.
Основными методами, или группами процессов, используемыми при управлении
проектами, являются:
Инициация;
 Планирование
 Исполнение


Мониторинг и Контроль
 Завершение.
Основными элементами управления проекта являются:
Определение требований;
 Установка четких и достижимых целей;
 Уравновешивание противоречащих требований по качеству, содержанию,
времени и стоимости;
 Коррекция характеристик, планов и подхода в соответствии с мнением и
ожиданиями различных заинтересованных сторон проекта

Одним из важнейших характеристик управления
проектами является так называемое «тройное
ограничение», которое включает три параметра –
содержание проекта, его время и стоимость, которые
необходимо учитывать при согласовании разнообразных
требований проекта. Умение находить баланс между
этими параметрами определяет качество выполнения
проекта.
Факторы времени, стоимости и содержания проекта имеют принципиальное значение для
его заинтересованных сторон. Оценивая качество выполненного проекта,
заинтересованные стороны в первую очередь будут задаваться следующими вопросами:
 Сделали ли Вы то, что я ожидал от Вас? (содержание)
Сделали ли Вы это в срок, который я определил для Вас? (время)
Уложились ли Вы в ту сумму, которая вам была выделена? (стоимость)


Эти три характеристики проекта взаимозависимы и имеют первостепенное значение на
всех этапах реализации проекта. Например, при расширении целей проекта,
одновременно потребуется увеличение финансирования, а также продолжительности
проекта. Точно так же, если принято решение сократить сроки действия проекта, то
потребуется увеличение ресурсов, а также сокращение поставленных целей.
Проекты, выходящие за пределы установленных сроков, превышающие предполагаемый
бюджет, а также не достигшие намеченных целей считаются неудовлетворительными.
Поэтому, важнейшим элементом управления проектами являются определение
необходимых ресурсов, их обеспечение, а также регулирование и управление ими в ходе
реализации проекта для того, чтобы применить в других сферах деятельности
организации после того, как проект завершится.
Важно отметить, что необходимой частью проекта является соблюдение этических
стандартов, профессиональной ответственности перед его заинтересованными
сторонами, в том числе перед заказчиком, исполняющей организацией и обществом в
целом.
Кроме того, в управлении проектами многие процессы являются итеративными
(повторяющимися) в силу наличия и необходимости последовательной разработки на
стадиях жизненного цикла проекта. Здесь имеется в виду, что по мере накопления знаний
о проекте, команда проекта может перейти к более детальному уровню его управления.
Необходимо иметь в виду, что термин «управление проектами» используется также для
описания организационного подхода к управлению текущими операциями, которые
можно приравнять к проектам. Это так называемое «управление посредством проектов».
3. Заинтересованные стороны
Заинтересованные стороны проекта – это лица или организации, активно участвующие в
работе проекта, либо заинтересованные в реализации его целей. Ключевыми
заинтересованными сторонами любого проекта являются:
Менеджер проекта. Лицо, ответственное за управление проектом;
Заказчик/пользователь. Лицо или организация, заинтересованная в
использовании результатов (продукта) проекта.
Исполнительная организация. Предприятие, чьи сотрудники непосредственно
участвуют в исполнении проекта.
Члены команды проекта. Группа, выполняющая работы по проекту.
Команда управления проектом. Члены команды проекта, непосредственно
занятые в управлении его операциями.
Спонсор. Лицо или группа лиц, предоставляющая финансовые ресурсы для
проекта.
Источники влияния. Лицо или группы, которые напрямую не связаны с
получением или использованием продукта проекта, но которые в связи с их
статусом в организации-заказчике или исполняющей организации могут
положительно или отрицательно повлиять на ход развития проекта.
Офис управления портфелем проектов (PMO). Если в исполняющей
организации имеется этот офис, он может выступать в качестве заинтересованной
стороны проекта, если он несет прямую или непрямую ответственность за
результаты проекта.
Помимо вышеперечисленных типов заинтересованных сторон проекта, выделяют также
внутренние и внешние стороны, владельцев и инвесторов, продавцов и подрядчиков,
правительственные учреждения и СМИ, временные или постоянные лоббистские
организации, отдельные граждане и общество в целом.
Заинтересованные стороны проекта имеют различные уровни ответственности и
полномочий, которые могут изменяться на разных этапах жизненного цикла проекта.
Таким образом, можно выделять ключевые, второстепенные и периферийные сторон
проекта. Разница между ними состоит в степени влияния на проект. Так, периферийные
стороны не имеют прямого влияния на принятие решений, однако иногда способны
коренным образом изменить развитие проекта, вплоть до его закрытия.
Задачей команды управления проектом является выявление сторон, определение их
требований и ожиданий и регулирование их влияния на развитие проекта. На рисунке.
показаны отношения между заинтересованными сторонами и командой проекта.
Заинтересованные стороны проекта Отношения между заинтересованными
лицами проекта и проектом
и уровни их влияния на проект
Кроме того, заинтересованные стороны проекта могут оказывать как положительное, так
и отрицательное влияние на проект. В первом случае обычно имеются в виду те
заинтересованные стороны проекта, которым выгодно успешное завершение проекта,
тогда как во втором случае имеются в виду стороны, которым невыгоден его
благоприятный исход. Так, при развитии проекта индустриального характера сторонами,
положительно влияющими на его развитие, окажутся деловые круги общества, которые
видят в нем экономическую пользу, а отрицательно влияющими сторонами могут стать
группы по защите окружающей среды, считающие, что проект наносит вред природе.
Основные исполнители проекта, или команда проекта – это те, кто ежедневно работают,
несут ответственность за продвижение проекта до момента его окончания, а также при
необходимости изыскивают дополнительные ресурсы для успешного его завершения. В
работе проекта участвуют также сотрудники юридических и муниципальных служб, чье
одобрение необходимо для повышения статуса проекта.
Главной задачей менеджера является четкое определение роли и ожиданий
заинтересованных сторон проекта, которые необходимо учитывать на каждом этапе
реализации проекта.
Роль ожиданий заинтересованных сторон проекта
Область знаний и процессов управления проектами
УПРАВЛЕНИЕ ПРОЕКТАМИ
Управление интеграцией проекта
1. Разработка Устава проекта
2. Разработка предварительного
описания содержания проекта
3. Разработка плана управления
проектом
4. Руководство и управление
исполнением проекта
5. Мониторинг и управление
работами проекта
6. Общее управление изменениями
7. Закрытие проекта
Управление стоимостью проекта
1. Стоимостная оценка
2. Разработка бюджета расходов
3. Управление стоимостью
Управление
содержанием проекта
1. Планирование
содержания
2. Определение
содержания
3. Содержание ИСР
4. Подтверждение
содержания
5. Управление
содержанием
Управление сроками проекта
1. Определение состава
операций
2. Определение взаимосвязей
операций
3. Оценка ресурсов операций
4. Оценка длительности
операций
5. Разработка расписания
6. Управление расписанием
Управление качеством
проекта
Управление человеческими
ресурсами проекта
1. Планирование качества
2. Процесс обеспечения
качества
3. Процесс контроля
1. Планирование человеческих
ресурсов
2. Набор команды проекта
3. Развитие команды проекта
качества
Управление коммуникациями
проекта
Управление рисками
проекта
1. Планирование коммуникаций
2. Распространение информации
3. Отчетность по исполнению
4. Управление участниками проекта
1. Планирование
управления рисками
2. Идентификация рисков
3. Качественный анализ
рисков
4. Количественный анализ
рисков
5. Планирование
реагирования на риски
6. Мониторинг и
управление рисками
4. Управление командой
проекта
Управление поставками
проекта
1. Планирование покупок и
приобретений
2. Планирование контрактов
3. Запрос информации у
продавцов
4. Выбор продавцов
5. Администрирование
контрактов
6. Закрытие контрактов
4. Кто такой менеджер проектов?
Менеджер проекта играет особую роль в развитии проекта. Существуют определенные
черты, которыми должен обладать менеджер проекта. Именно он занимается подбором
персонала, определяет необходимые шаги, которые должны быть предприняты для
достижения целей проекта.
Менеджер должен сформировать правильное понимание результатов проекта, и донести
их до членов команды таким образом, чтобы воодушевить их на активную работу. Люди,
которые в силу характера или других факторов склонны откладывать решение проблем,
или вовсе игнорировать таковые в надежде, что проблемы исчезнут сами по себе, не
могут подойти на роль эффективного менеджера проекта.
Эффективный менеджер проекта должен задавать себе следующие вопросы: «Что мне
следует сделать, чтобы заранее предусмотреть возникающие в ходе развития проекта
трудности, каким образом я могу это предотвратить?».
Главная роль в определении управления проектами отведена ожиданиям
заинтересованных сторон проекта, точнее оправданию возложенных надежд. В
соответствии с их ожиданиями и определяется направление работы проекта, а также
принимается решение относительно того, достигнуты ли цели проекта или нет.
Здесь вовсе не имеется в виду, что менеджер проекта обязан бездумно выполнять все
пожелания сторон, заинтересованных в проекте. Менеджер проекта должен уметь
взаимодействовать со всеми лицами, так или иначе заинтересованными в проекте,
обсуждать с ними выбранное направление развития проекта, а также сопротивляться
новым ожиданиям, которые могут появляться у заинтересованных сторон в отношении
проекта.
Правильный менеджмент подразумевает, во-первых, выяснение интересов всех
заинтересованных сторон проекта, включая периферийных, которые, как правило, не
определяют траекторию развития проекта, но в то же время могут существенно повлиять
на развитие проекта. Затем менеджер должен правильно сформировать у команды
проекта понимание ожиданий сторон проекта. На начальном этапе менеджер проекта
проводит встречи с заинтересованными сторонами проекта для выяснения их ожиданий,
а затем наступает момент, когда ожидания следует документально зафиксировать, и
далее их больше не обсуждать.
По мере продвижения проекта команда сотрудников может меняться, компании
реорганизуются, и все окружение проекта в целом может наносить ущерб развитию
проекта. И только менеджер проекта обязан продолжать контролировать выполнение
ожиданий заинтересованных сторон проекта.
А что, если заинтересованные стороны проекта пересмотрели свои ожидания от проекта?
Существование всего проекта может быть под вопросом. Менеджер проекта должен
удостовериться, что проект все еще актуален и значим для организации, у которой
появились новые ожидания от проекта.
Общеизвестно, что для менеджера проекта успех определен ожиданиями. Именно
заинтересованные стороны проекта являются судьями проекта, и они оценивают,
насколько успешным является проект.
5. Организационные структуры и роль
менеджера проектов в каждой из них
Структура организации, ответственной за исполнение проекта, во многом накладывает
ограничения на доступность ресурсов. Эта структура может быть как функциональной,
так и проектной, при чем в данный диапазон могут включаться разные подвиды
матричных структур. В таблице приведены ключевые характеристики, относящиеся к
проектам, для основных типов оргструктур.
Влияние организационной структуры на проект
Характеристики
проекта
Функциональная
Структура организации
Матричная
Слабая
Ограничены
Проектная
Сбалансированная Жесткая
Низкий или
Средний Высокий
средний уровень
или
уровень или
высокий практически
уровень полный
контроль
Полномочия
менеджера
Незначительные
или же их нет
Наличие ресурсов
Незначительные
или же их нет
Кто контролирует
бюджет проекта
Функциональный Функциональный Смешанный
руководитель
руководитель
Менеджер Менеджер
проекта проекта
Роль менеджера
проекта
Частичная
занятость на
Полная
Полная
занятость занятость на
Ограничены
Частичная
занятость на
Низкий или
средний уровень
Полная занятость
на проекте
Средний
или
высокий
уровень
Высокий
уровень или
практически
полный
контроль
проекте
проекте
Административный Частичная
персонал проекта занятость на
проекте
Частичная
занятость на
проекте
на
проекте
Частичная
занятость на
проекте
проекте
Полная
Полная
занятость занятость на
на
проекте
проекте
Классическая функциональная организация представляет собой иерархическую
структуру, в которой каждый служащий имеет одного четко выделяемого руководителя.
Персонал группируется по специальностям, в рамках которых могут также существовать
функциональные организации, поддерживающие работу основной организации.
Содержание проектов, выполняемых в функциональной организации, ограничено
рамками функционального подразделения.
В проектной организации члены команд зачастую собраны в одном месте. Большая часть
ресурсов задействована в работе проектов, причем их менеджеры обладают
независимостью и большими полномочиями.
Матричная организация представляет собой сочетание функциональной и проектной
организации. Поэтому следует различать виды матричных структур - слабая,
сбалансированная и сильная - которые отличаются друг от друга степенью проявления
черт функциональной или проектной оргструктуры. Так, в слабых матричных
оргструктурах сохраняются многие характеристики функциональной организации,
поэтому функция менеджера в ней чисто координационная. В то же время, в сильных
матричных структурах штатные менеджеры проектов могут обладать значительно
большим спектром полномочий, чем в классической организации.
Большая часть современных организаций являются смешанными и включают в себя эти
структуры на разных уровнях своей иерархии. Даже полностью функциональная
структура может создать специальную проектную команду для управления критически
важными проектом.
6. Составные стадии проекта
(инициирование, планирование,
выполнение, мониторинг и контроль,
закрытие)
В соответствии с вышесказанным, управление проектами – это приложение знаний,
навыков, инструментов и методов к операциям проекта для удовлетворения требований,
предъявляемых к проекту. Управление проектом выполняется с помощью процессов с
использованием специальных знаний, навыков, инструментов и методов по управлению
проектами.
Процесс – это ряд взаимосвязанных действий и операций, выполняемых для достижения
заранее определенных результатов (продуктов или услуг). Процессы управления
проектом выполняются командой проекта и бывают двух типов:

Процессы, общие для большинства проектов и связанные между собой тем, что
они нацелены на выполнение общей задачи.
 Процессы, ориентированные на определение и создание продукта проекта.
Данные процессы определяются через жизненный цикл проекта и меняются в
зависимости от области приложения.
Для того чтобы успешно выполнить и завершить проект, команда проекта должна:
Выбрать из групп процессов управления проектом те, которые необходимы для
достижения поставленных целей;
 Использовать определенный подход для согласования планов и спецификаций
продукта с требованиями к продукту и проекту;
 Исполнять требования, чтобы соответствовать нуждам, желаниям и ожиданиям
заинтересованных сторон проекта;
 Уравновешивать противоречащие требования по объему, времени, стоимости,
качеству, ресурсам и рискам, чтобы произвести качественный продукт.

Исходной идеей для взаимодействия между процессами управления проектом является
цикл «планирование-исполнение-проверка-воздействие», предложенный Уолтером А.
Шьюартом и доработанный У. Эдвардсом Демингом. Как показано на рисунке, этот цикл
связан результатами – результат одной части цикла становится входом другой части.
Цикл «планирование-исполнение-проверка-воздействие»
Диаграмма взаимодействия процессов дает общее представление об основных
зависимостях и взаимодействиях между группами процессов. Группа процессов
включает составные процессы управления проектами, которые связаны
соответствующими входами и выходами, т.е. результат одного процесса становится
входом другого.
Кроме того, следует учесть, что группы процессов – это не то же самое, что фазы
проекта. Если проекты могут быть разбиты на отдельные фазы или подпроекты, то все
группы процессов будут, как правило, применяться к каждой фазе или подпроекту. Ниже
приведены пять групп процессов:
Группа процессов инициации определяет и авторизует проект или фазу проекта.
• Группа процессов планирования определяет и уточняет цели и планирует
действия, необходимые для достижения целей и содержания, ради которых был
предпринят проект.
• Группа процессов исполнения объединяет человеческие и другие ресурсы для
выполнения плана управления проектом данного проекта.
• Группа процессов мониторинга и управления регулярно оценивает прогресс
проекта и осуществляет мониторинг, чтобы обнаружить отклонения от плана
управления проектом, и, в случае необходимости, провести корректирующие
действия для достижения целей проекта.
• Группа завершающих процессов формализует приемку продукта, услуги или
результата и подводит проект или фазу проекта к правильному завершению.
Схема взаимодействия между группами процессов управления проектом
7. Жизненный цикл проекта
Ключевым понятием как в управлении проектами, так и в самих проектах является
жизненный цикл проекта. Данное понятие означает совокупность фаз, которые
связывают начало проекта с его завершением и обеспечивают его качественное
управление с соответствующими отсылками на текущие операции исполняющей
организации.
Жизненный цикл проекта
Приведенный выше рисунок необходим для понимания правильного подхода в изучении
управления проектами. Для финансирования растущего уровня активности в проекте мы
можем заранее предусматривать увеличение требуемых ресурсов. Это выражается в
привлечении требуемых специалистов, оборудования и даже производственных
мощностей, необходимых для достижения целей проекта. Таким же образом следует
планировать сокращение ресурсов на стадии его завершения. Таким образом, подъемы и
падения жизненных циклов, и соответствующие изменения в прилагаемых усилиях и
требуемых ресурсах помогают нам правильно планировать развитие проекта, а также
правильно сформировать кривую, отображающую усилия, прилагаемые на протяжении
срока проекта.
Жизненный цикл (далее – ЖЦ) проекта следует рассматривать как совокупность фаз.
Фазы жизненного цикла проекта не совпадают с вышеописанными группами процессов
управления проектом. Переход из одной фазы в другую в пределах ЖЦ проекта обычно
подразумевает некую форму технической передачи или сдачи результатов. Однако
иногда фаза может начаться до одобрения результатов завершения и сдачи
предшествующей фазы в тех случаях, когда сопутствующий этому риск рассматривается
как приемлемый. Подобная практика наложения фаз является примером метода сжатия
расписания, который называется «быстрый проход».
Не существует одного наилучшего способа определения идеального ЖЦ проекта.
Общеотраслевые принципы часто обуславливают использование предпочтительного ЖЦ
в той или иной отрасли.
ЖЦ проекта обычно определяет следующее:

Какие технические работы должны быть проведены в каждой фазе;
В какой момент каждой фазы должны быть получены результаты поставки и как
проходит проверка и подтверждение каждого результата поставки
 Кто является заинтересованными сторонами каждой фазы
 Как контролировать и подтверждать каждую фазу

Многие ЖЦ проектов имеют ряд общих характеристик:
Фазы обычно идут последовательно и ограничиваются передачей технической
информации или сдачей технического элемента проекта;
 Уровень затрат и численность задействованного персонала вначале как правило
невелики, увеличиваясь по ходу выполнения проекта и быстро падая на
завершающем этапе проекта;
 Уровень неизвестности и, следовательно, риск недостижения целей наиболее
велики в начале проекта. По ходу выполнения проекта уверенность в его
завершении, как правило, увеличивается.
 Способность заинтересованных сторон проекта повлиять на конечные
характеристики продукта проекта и окончательную стоимость проекта
максимальны в начале проекта, и уменьшаются по ходу его выполнения. Это
объясняется тем, что стоимость внесения изменений в проект и исправления
ошибок в общем случае возрастает по ходу выполнения проекта.

Фаза проекта характеризуется завершением и одобрением одного или нескольких
результатов проекта. Результат проекта – это измеримый, проверяемый продукт
работы, например спецификация, отчет по анализу осуществимости, детальный план или
опытный образец. Результаты проекта, а значит и фазы, являются частью общего
последовательного процесса, предназначенного для обеспечения необходимого контроля
над проектом и получения нужного результата, являющегося целью проекта.
В каждом конкретном проекте фазы могут разбиваться на подфазы исходя из
соображений сложности, уровня риска и ограничений на порядок финансирования. Фаза
проекта обычно завершается изучением проделанной работы и результатов поставки с
тем, чтобы определить, насколько они приемлемы, и решить, необходимы ли еще
дополнительные работы или фазу можно считать закрытой.
Формальное завершение фазы проекта не включает в себя авторизацию последующей
фазы. Для обеспечения эффективного контроля в каждой фазе формально имеется своя
группа процессов инициации, на выходе которой получает специфичный для данной
фазы выход. Этот выход определяет, что для данной фазы полагается и что от нее
ожидается, как показано ниже.
Последовательность фаз в жизненном цикле проекта
При разработке ЖЦ проекта необходимо понимать, что данное понятие не является
синонимом ЖЦ продукта. Например, проект, целью которого является выпуск на рынок
нового персонального компьютера, является лишь одним из аспектов ЖЦ продукта.
Таким образом, ЖЦ проекта состоит из серии фаз создания продукта. Дополнительные
проекты могут заключаться в повышении производительности продукта. На рисунке
показана взаимосвязь ЖЦ проекта и продукта.
Взаимосвязь между жизненными циклами проекта и продукта
8. Выбор и приоритезация проектов
На сегодняшний день почти все организации имеют намного больше проектов, чем
реально можно осуществить. Есть проекты, которые должны быть внедрены ввиду
морального износа оборудования, нормативных требований и т.д. Есть и другие проекты,
которые принесут компании внутренние усовершенствования, например, в форме
снижения расходов, роста качества продукции, улучшения морального духа коллектива.
Также существуют проекты, которые инициируются с целью роста доходов организации
путем создания и развития новых продуктов, вхождения в новые сегменты рынка и
установления партнерских отношений с другими фирмами.
По данным исследований, сталкиваясь с таким разнообразием потенциальных проектов,
фирмы неизбежно совершают ошибку. Они пытаются реализовать всё сразу.
Организации переоценивают свои возможности и берутся за большее число проектов,
чем способны реализовать.
Таким образом, перед тем как непосредственно приступить к управлению проектами,
необходимо определить их приоритетность, выбрать оптимальное количество проектов, а
также персонал и финансирование, необходимые для их выполнения. Данный процесс
отбор проектов является частью более крупного процесса, обозначаемого как
«портфельный менеджмент».
Зачастую менеджеры проектов не вовлекаются непосредственно в выбор тех или иных
проектов организации, однако им важно понимать, каким образом проекты были
отобраны. Как правило, выбор и приоритезация проектов основывается на анализе
следующих критериев.
Риск. Все проекты обладают той или иной степенью риска. Как правило, чем больше
риск, тем менее привлекателен проект для организации. В то же время, проект
необходимо рассматривать с различных углов зрения, поскольку непринятие и отказ от
реализации проекта также является риском. Критерий риска позволяет определить, что за
тот или иной проект стоит браться в том случае, если вероятность успешной реализации
его целей достаточно высока.
Новые технологии/навыки. Проект, который дает организации шанс посредством
внедрения новых технологий / приобретенных навыков получить новый опыт и развивать
желаемое и необходимое, является более привлекательным, чем тот, что не
предоставляет возможности вырасти в этих направлениях. В действительности,
некоторые проекты создаются исключительно в целях совершенствования и роста
компании в тех областях, в которых она заинтересована. С этой точки зрения, проект –
способ, позволяющий организации развиваться и быть конкурентоспособной.
Установление взаимоотношений. Большая часть проектов ставит перед собой задачу
установления взаимовыгодных отношений и контактов с партнерами по бизнесу и
заказчиками, которые смогут принести нам успех в бизнесе.
Удовлетворение запросов клиентов. Многие проекты создаются для того, чтобы
поддерживать хорошие отношения со своими клиентами. Надо исходить из того, что
выбор в пользу того или иного проекта определяется его ценностью для потребителя.
Период окупаемости капиталовложений (PBP). Одним из финансовых методов
определения приоритетности проекта является расчет срока возврата капиталовложений.
Он означает ожидаемый период времени, в течение которого прогнозируемые
поступления денежных средств от реализации проекта превысят сумму инвестиций.
Период окупаемости инвестиций может занимать от 6 месяцев (для быстрореализуемых
проектов, например, таких как совершенствование технологий для снижения затрат на
рабочую силу) до 5 лет (например, строительство или внедрение крупномасштабных
систем).
Чистая приведенная стоимость (NPV). Расчет чистого приведенного дохода (ЧПД)
означает временную стоимость вложений. Реализуя проектную работу, мы ожидаем
получения доходов от экономии на издержках как можно скорее, при этом увеличивая
максимально возможно сроки расходования средств. Это и есть управление
финансовыми потоками (управление ликвидностью). В то же время необходимо
понимать, что не каждый проект, который обещает наибольший доход, стоит того, чтобы
вкладывать в него средства. Поэтому расчет ЧПД является показателем того, стоит ли
начинать проект или нет.
Прибыль на инвестированный капитал (ROI) – показатель рентабельности
инвестиций означает ожидаемую прибыль, которую планируется получить по
инвестициям, вложенным в проект. Проекты с наибольшим показателем ROI являются,
как правило, более привлекательными, чем другие.
Требования проекта – некоторые проекты обладают первостепенной важностью в силу
требований, которые они налагают на нас. Так, например, дефект в информационной
системе космического аппарата Шаттл является критически важной задачей, требующей
немедленного решения. Или, федеральная служба госнадзора по технике безопасности
требует внедрения новых правил в строительных проектах, соответствующие закону об
охране труда. Таковы примеры проектов высокой категории срочности.
Одним из наиболее частых заблуждений является то, что для многих процесс
приоритезации проектов представляется не особо важным, и выстроить его можно на
основе двух или трех вышеприведенных методов. Тем не менее, делать это, полагаясь
только на показатели степени риска или расчета NPV, будет крайне ошибочным.
Поэтому необходимо составить шкалу приоритетности проектов, оценивая в первую
очередь нефинансовые показатели – уровень развития технологий или степень
удовлетворенности потребителей. Именно они помогут выстроить систему
приоритезации проектов как можно более объективно.
2. Инициирование проекта
1. Как описать общие цели
и задачи проекта на этапе зарождения
2. Составление устава проекта
3. Результаты этапа инициации
1. Как описать общие цели
и задачи проекта на этапе зарождения
Как было отмечено ранее, проекты инициируются с целью создания уникального
продукта или услуги. Необходимость начать проект может быть продиктована
потребностями внешней (конкурентами, поставщиками, правительством) или
внутренней (работники, менеджеры, аудиторы компании) среды.
Во многом, от наших знаний и умений правильно определять приоритетные проекты
зависит то, насколько успешно будет развиваться компания в будущем. Поэтому на
этапе зарождения проекта важно собрать команду и провести «мозговой штурм». Для
определения ключевых вопросов проекта рекомендовано придерживаться следующих
правил.
Определить рамки обсуждения и цели мозгового штурма
Дать каждому возможность высказать свое мнение
Не допускать критики высказываемых идей. Цель мозгового штурма –
генерировать идеи, а не оценивать или сортировать их
 Назначить секретаря, который будет фиксировать все идеи.



Результатом мозгового штурма является перечень потребностей, среди которых
отбираются те, которые в действительности заслуживают реализации в рамках проекта.
Советуем группировать эти потребности по категориям для того, чтобы облегчить
процедуру их обсуждения и приоритезации.
Находить новые потребности
Многие потребности так и остаются не озвученными, поэтому необходимо тщательно
изучить и выявить их. Конечно, книга жалоб и предложений, система оценки
полученных знаний по окончании курсов обучения или проведение предпродажных
исследований являются стандартными методами изучения потребностей, которых может
не знать поставщик товаров.
Организация, желающая успешно продолжать свою деятельность, должна постоянно
находиться в поиске новых потребностей, а затем из них отбирать те, которые будут
реализованы в рамках проекта.
Смоделировать концепцию продукта
Одним из способов стимулирования обсуждения потребностей при встрече с конечными
пользователями и другими заинтересованными сторонами проекта является разработка
концепции продукта. Сторона конечного пользователя в ходе таких обсуждений
выдвигает большое количество требований к продукту. Речь идет о пилотных моделях и
других визуальных инструментах, которые можно видеть и осязать. Например, в
автомобильной промышленности часто используются так называемые концепт-кары
(автомобили, изготовленные в одном или нескольких экземплярах и предназначенные
для демонстрации на выставках и т.п.) для того, чтобы привлечь внимание
потенциальных покупателей или вызвать критику.
Оценить стратегические цели
Стратегическая оценка деятельности компании является стимулом к генерированию и
структурированию специфических целей компании, которые, в конечном счете, могут
стать основой развития некоторых проектов. Для любой организации полезно время от
времени остановиться и обдумать, где и какой она хочет быть через 3-10 лет, и что
требуется для того, чтобы достичь этих целей. Множество фирм расценивают портфель
имеющихся проектов в качестве важнейшего инструмента, используемого для
достижения корпоративных целей. Проекты и потребности, лежащие в их основе,
являются ключом к реализации стратегических целей компании.
Определить операционную эффективность
Потребности можно также выявить, оценивая текущее положение дел в компании. Так,
задержки продаж по какой-либо продуктовой линейке, доступность информации для
клиентов и конечных потребителей, использование методов повышения качества
продуктов, а также другие аналогичные методы являются типичными способами
выявить потребности, нуждающиеся в улучшении.
Провести анализ рынка и внешней среды
Проведение формальных исследований также играет важную роль в идентификации
потребностей, которые впоследствии могут привести к созданию проекта. Компания не
сможет выжить, если она не будет постоянно проводить анализ конкурентной среды для
выявления потребительских предпочтений, отслеживать деятельность конкурентов и
предпринимать ответные действия, определять новые требования рынка и способы
получения прибыли. В данном случае в первую очередь имеется в виду маркетинговые
исследования, включая организацию фокус-групп с потенциальными потребителями,
опрос экспертов в сфере госуправления и новых технологий, а также приобретение
исследований, проведенных консалтинговыми и маркетинговыми агентствами.
Оценить тенденции
Тренды представляют собой прогноз будущего развития или возникающих нужд и
запросов внешней среды. Обзор возможных изменений в сфере развития и
использования технологий, потребительского поведения (в том числе – растущее число
покупок при помощи дебетовых и кредитных карт вместо наличных денег), или оценки
продаж и каналов дистрибуции могут стать идеальными способами определения
возникающих потребностей.
Провести встречу с потребителями и пользователями будущих результатов
проекта
Самым ценным и, пожалуй, стоящим методом определения потребностей является
встреча с конечными потребителями разрабатываемой продукции или услуги, которые
должны ответить на вопрос, каковы их требования и ожидания и как они могут
измениться в будущем. Несмотря на кажущуюся легкость данного метода, необходимо
должным образом подготовиться к этой встрече, чтобы обеспечить себе успех. Иными
словами, следует определить:
Кто является конечным потребителем результатов проекта в настоящем и
будущем? Например, большинство информационных систем, созданных
несколько лет назад были предназначены для профессионалов в области
туристического бизнеса. Именно и только они занимались бронированием
авиабилетов и гостиничных мест. В настоящее время созданы новые
информационные системы, которые позволяют туристу самостоятельно ее
использовать. При определении конечного потребителя следует также подумать о
том, что новый продукт может продаваться одним человеком, быть куплен
другим, а обслуживаться третьим. Кто из них является конечным потребителем?
Возможно все перечисленные группы можно отнести к конечным потребителям?
Компания должна ответить на подобные вопросы, прежде чем начинать какиелибо исследования. В противном случае, многие важные требования,
предъявляемые к новому продукту, будут упущены.
Что потребуется потребителям в будущем? На это трудно ответить.
Предположим, что для достижения целей проекта нам потребуется не менее трех,
а то и более лет. Очень важно, чтобы те задачи, которые проект призван решить,
имели отношение не только к настоящим потребностям. Трудность здесь будет
состоять в том, чтобы определить потребности, которые могут возникнуть в
будущем. Именно этот фактор играет основную роль для правильного построения
проекта. Значительные средства и усилия будут затрачены на достижение целей
проекта. Важно, чтобы эти цели соответствовали реальным потребностям.
Определение потребностей
Некоторые потребности могут быть не вполне понятны. Как правило, потребители не
заявляют об имеющихся потребностях, поэтому, многие из них так и остаются не
высказанными. Распознать потребности, которые, возможно, будут актуальны в
будущем, скажем, лет через 5, довольно сложно. Специалисты, в чьи задачи входит
инициация проектов, должны приложить усилия для определения такого рода
потребностей, пользуясь методикой, представленной выше. Это серьезная работа! И
такую работу, равно как и все связанные с нею затраты, необходимо планировать
заранее. Нет оснований думать, что знания о будущих потребностях могут появиться у
нас сами собой, без приложения усилий. Постоянный анализ потребностей отличает
успешную компанию от менее успешных.
Извлечение информации о тех потребностях, которые не лежат на поверхности, или
метод «зреть в корень»?В ходе исследования потребностей часто приходится доходить
до самой сути потребностей. Итак, возвращаясь к нашему строительному проекту,
представим, что руководитель компании, осуществляющей строительство зданий,
заявил, что бюджет строительства двух последних зданий значительно превысил ранее
заложенный, и как следствие, следует использовать более рентабельные методы
строительства. Заметьте, что здесь указаны скорее симптомы, а не истинные причины
проблемы. Следует определить главную проблему, именно она продуцирует симптомы, а
иногда порождает и сопутствующие проблемы. Именно эта причина или потребность
должна стать основой проекта.
Только представьте, что может произойти, если за основу проекта берется не основная
потребность, а симптом. Допустим, для того, чтобы сократить бюджетные расходы, мы
инициируем проект по найму плотников, которые готовы работать за меньшую плату.
Будет ли это решением проблемы? Нет, если суть проблемы заключается в технологии
строительства. Таким образом, для решения ключевой проблемы потребуется создать
совершенно другой проект, не имеющий ничего общего с проектом по найму дешевых
плотников.
Желания не идентичны потребностям. Сотрудники команды, исследующие
потребности, нередко сталкиваются с людьми, которые настаивают на своих
«потребностях». Однако при дальнейшем рассмотрении выясняется, что предложенные
ими потребности относятся скорее к разряду «было бы здорово если...». Трудность в том,
чтобы уметь выявлять самые ценные потребности, необходимые для компании,
потребителей и всех заинтересованных сторон проекта.
Потребительские нужды не могут являться единственным критерием для отбора
потребностей. Компания проводит оценку применительно к своему собственному
бизнесу. Кроме того, существуют потребности, определяемые государством или
органами государственного регулирования. Такие проекты просто должны быть
выполнены, хотя они имеют слабое влияние на потребителей.
2. Составление устава проекта
Завершив определение требований к проекту, мы можем перейти к следующему уровню
управления проектом. Здесь мы обозначим его структуру, его составные части и способы
их контроля. На данном этапе, речь пойдет о том, как правильно:
Обозначить границы проекта, которые помогут определить его масштабы и
содержание;
 Стимулировать обсуждение среди заинтересованных сторон проекта о том, что
требуется для составления плана проекта и его реализации;
 Создать максимум возможной информации о проекте с целью сравнения с
другими аналогичными проектами, и возможностью использовать полученные
результаты.
 Добиться консенсуса между заинтересованными сторонами проекта касательно
основного содержания проекта.

Как ни странно, но начальная стадия проекта считается наиболее сложной. Каждая
заинтересованная сторона проекта имеет свое видение того, каким должен быть проект,
т.к. каждый преследует свои собственные цели.
Многие из тех, кто работает в технической сфере, не четко представляют свои конечные
цели на этапе инициации проекта. В литературе такое состояние называют "fuzzy front
end"- неясность начального этапа». Имеется в виду, что определены проблемы, но не
ясны методы их решения. Основным способом преодоления этой неясности является
составление программного документа – Устава проекта. Устав проекта позволяет
сформулировать цели проекта на более высоком уровне и достичь соглашения по
вопросу содержание проекта.
Составление проекта Устава и распространение его среди заинтересованных сторон
проекта с целью обсуждения и включения предложенных изменений поможет заложить
прочный фундамент для дальнейшего планирования проекта. Таким образом, пока не
будет найден компромисс по основным пунктам Устава, нет смысла двигаться дальше и
детализировать задания и, тем более, приступать к их исполнению.
Устав проекта – основополагающий документ проекта
Устав проекта является документом, формально разрешающим начало работы на
проекте. Он наделяет менеджера проекта полномочиями задействовать ресурсы
организации на операциях проекта.
Устав проекта составляется инициатором проекта или спонсором, не входящим в
организацию проекта и имеющим достаточные полномочия для его финансирования.
Как правило, составление Устава проекта и его авторизация происходят за пределами
организации проекта.
Создание Устава проекта является звеном, соединяющим проект с текущей работой
организации. Разработка Устава проекта в первую очередь связана с документированием
производственной необходимости, обоснованием проекта, текущим пониманием
потребностей заказчика и нового продукта, услуги или результата, призванными
удовлетворить эти потребности.
Устав проекта непосредственно или со ссылкой на другие документы должен содержать
следующую информацию.
Требования, удовлетворяющие потребности, пожелания и ожидания заказчика,
спонсора и других заинтересованных сторон проекта
 Производственная необходимость, общее описание проекта или требования к
продукту, который является предметом проекта
 Цель или обоснование проекта
 Информация о назначенном менеджере проекта и уровне его полномочий
 Расписание контрольных точек замера успешности проекта
 Отношения между заинтересованными сторонами проекта
 Функциональные организации и их участие
 Допущения относительно организации и окружения, а также внешние допущения
 Ограничения относительно организации и окружения, а также внешние
ограничения
 Реальная бизнес-ситуация, ставшая обоснованием проекта с данными о прибыли
на инвестиции
 Бюджет проекта.

В многофазных проектах часть процесса разработки Устава является утверждение на
последующих фазах решений, принятых при его первоначальной подготовке. В таком
случае имеет место следующая схема разработки Устава.
Разработка Устава проекта
Разработка устава проекта: вводные документы
1. Контракт (если требуется) приобретающей организации заказчика, если проект
выполняется для стороннего заказчика.
2. Содержание работы по проекту – описание представляемых проектом продуктов и
услуг:
Производственная необходимость – практическая необходимость организации,
которая может основываться на необходимости обучения, рыночном спросе,
техническом прогрессе, юридических требованиях или государственном
стандарте.
 Определение содержания продукта – документация требования к продукту и
характеристики продукта или услуги, для создания которых был предпринят
проект.
 Стратегический план – план, составленный для реализации стратегических целей
организации.

3. Факторы внешней среды предприятия – условия внешней среды и системы,
окружающие проект и влияющие на его успешность:
 Организационная культура и структура
Государственные и промышленные стандарты
Инфраструктура (сооружения, оборудование)
 Существующие человеческие ресурсы
 Управление персоналом
 Корпоративная система авторизации работ
 Ситуация на рынке
Толерантность к риску заинтересованных сторон проекта
 Коммерческие базы данных
 Информационные системы управления проектами



4. Активы организационного процесса - опыт и знания, накопленные из предыдущих
проектов, например завершенные расписания, данные о рисках и освоенных объемах.
Активы оргпроцесса могут быть сгруппированы в две категории:
Процессы и процедуры организации для проведения работ, в том числе принятые
в организации стандарты, корпоративные правила, жизненные циклы продукта и
проекта, политика и процедуры в отношении качества, процедуры финансового
контроля, управления проблемами и дефектами и т.д.
Корпоративная база знаний для хранения и извлечения информации, в том числе
информация и база накопленных знаний, база данных управления конфигурацией,
включая версии и планы всех официальных корпоративных стандартов,
регламентов, финансовая база данных и т.д.
Разработка устава проекта: вспомогательные инструменты и методы
1. Методы выбора проекта необходимы для определения того, какой проект выберет
организация. Как правило, выделяют две категории методов:

Методы измерения доходности (сравнительные подходы, экономические модели)
 Математические модели на основе линейных, нелинейных, динамических и
других алгоритмов.
2. Методология управления проектами определяет ряд групп процессов, которые
могут стать основой выработки стандарта управления проектами.
3. Информационная система управления проектами (ИСУП) представляет собой
стандартизированный набор имеющихся в организации автоматизированных
инструментов, интегрированных в систему.
4. Экспертная оценка применяется для оценки входов, необходимых для разработки
Устава проекта. Как правило, экспертиза осуществляется лицом или группой лиц,
имеющих специальные знания или подготовку в данной области (консультанты,
заинтересованные стороны проекта, заказчики или спонсоры, профессиональнотехнические ассоциации, отраслевые группы).
Выходным документом, суммирующим работу на данном этапе, является
разработанный Устав проекта.
3. Результаты этапа инициации
Организации, успешно инициирующие проекты, должны придерживаться следующих
правил.
Следует обосновать и доказать важность задач, решаемых в рамках проекта.
Следует предпринять активные меры по выявлению всех заинтересованных
сторон проекта, а также правильно понимать их требования и предпочтения по
отношению к проекту.
Следует отличать желания от потребностей.
Описание сферы деятельности проекта должно быть простым и понятным для
всех заказчиков и заинтересованных сторон проекта.
Следует установить приоритеты целей проекта, и, затем, следовать им на
протяжении работы всего проекта.
Следует исследовать тенденции и выстраивать проект на основе
прогнозируемых изменений внешней среды.
Следует определить объем и состав работ по проекту, добиться консенсуса от
заинтересованных сторон проекта относительно единого понимания проекта, а
также того, как им управлять.
Следует определить, планировать и отслеживать затраты на оплату труда в
денежном выражении или в человеко-часах.
Проекты, выполняемые для внутренних клиентов организации должны
выполняться в том же порядке, что и для внешних.
Организация в первую очередь должна осуществлять наиболее приоритетные
проекты, финансируя и обеспечивая их соответствующим персоналом.
Все заинтересованные стороны проекта, как внутри, так и вне организации,
участвующие в работе проекта на его начальном этапе должны правильно
понимать свои обязанности и полномочия. Устав проекта должен содержать
подобную информацию.
Следует выбрать сторону, финансирующую проект. Сторона должна быть
согласна с возлагаемой на нее ответственностью, а также должна регулировать
доступные ресурсы и сроки выполнения проекта.
Офис по Управлению Проектами, если таковой существует в организации,
должен принять на себя функции по курированию проекта и стандартизации
процессов.
Управление проектом может включать новые методы, но в разумных пределах.
Цели и задачи проекта должны быть понятны всем заинтересованным сторонам
проекта. Следует получить одобрение всех заинтересованных сторон проекта,
независимо от того, достигнуты ли цели проекта или нет.
3. Планирование проекта
1. Сбор требований к проекту
2. Что такое WBS и зачем она нужна?
3. Планирование качества
4. Оценка объема и стоимости работ
5. Подбор команды
6. Способы оценки сроков проекта
7. Планирование и управление рисками
8. Как принимать решения об аутсорсинге.
Виды контрактов
9. Результаты этапа планирования
1. Сбор всех требований к проекту
После того, как цель проекта согласована, следует поставить вопрос: «Что должно быть сделано,
чтобы достичь этой цели?». Мы должны правильно определить финальное содержание, цели и
задачи проекта. Без правильного определения этих параметров невозможно определить
длительность и стоимость проекта.
2. Что такое WBS и зачем она нужна?
С целью определения объема и содержания проекта, в управлении проектными работами
используется такой инструмент как иерархическая структура работ (WBS - work breakdown
structure).
Иерархическая структура работ (далее - ИСР) представляет собой перечень результатов
деятельности, которые необходимо достичь в установленные сроки до завершения проекта. ИСР
позволяет определить рамки проектной работы, помогает понять, какие работы уже завершены, и
каким образом построить дальнейшую работу. В процессе составления списка результатов проекта
мы можем их детализировать и выделить более конкретные результаты, что в конечном итоге
облегчит процессы планирования, оценки и контроля управления проектом. В этом смысле, ИСР
представляет своего рода вспомогательный механизм планирования и управления проектом.
Составление ИСР начинается с определения основных конечных результатов проекта. Среди них
выделяют следующие:
1. Список конечных потребителей
2. План
3. Результаты исследования
4. Итоговый отчет.
Однако, основываясь лишь на вышеперечисленных результатах, невозможно понять, каков объем
работ, необходимых для выполнения плана или сколько времени он займет. Поэтому данные
пункты требуют детализации, и тогда более подробная ИСР может выглядеть следующим образом.
1. Список конечных потребителей
1.1. Информирование заказчиков о проекте по
электронной почте
1.2. Встреча с руководителями департаментов
1.3. Перечень конечных потребителей
продукции/услуг.
2. План
2.1. Создание группы, ответственной за
планирование
2.2. Методология планирования
2.2.1 Перечень возможных методов проектной
работы
2.2.2 Отобранные метод(ы)
2.3. Ресурсы
2.4. Составление плана
3. Результаты исследования
4. Итоговый отчет
4.1. Список адресатов для рассылки документов;
4.2. Предварительный отчет
4.3. Итоговый отчет
Вышеприведенная ИСР является примером принципа «сверху-вниз», где конечные результаты
поделены на составляющие задачи. Данный подход приемлем для тех, кто уже имел опыт
составления ИСР и знаком с очередностью выполнения задач в процессе управления проектом.
Однако можно применить и иной подход. Например, собрать команду и устроить мозговой штурм,
в ходе которого можно сформулировать задачи, убрать повторяющиеся элементы и затем
сгруппировать их в логическом порядке. Здесь имеется в виду принцип «снизу-вверх». Этим
методом лучше пользоваться новичкам в данной сфере и тем, кто не знает, как достичь целей
проекта.
Независимо от того, какой метод вы предпочтете, ИСР должна обладать следующими атрибутами.
Все результаты должны быть ясно изложены и не требуют разъяснений. Вам, как менеджеру
проекта, необходимо четко понимать, что собой представляет тот или иной результат. Если вы не
уверены в правильности их формулировок, то, возможно, потребуется их переформулировать, а
затем согласовать изменения с другими заинтересованными сторонами проекта.
Заинтересованные стороны проекта должны способствовать процессу развития проекта. ИСР
обязательно должна создаваться при участии всей команды людей, выполняющих работы на
проекте. В то же время, одной из важнейших задач при разработке ИСР является информирование
лиц, непосредственно заинтересованных в проекте, относительно того, из чего состоит проект.
Если заинтересованные стороны проекта лишь формально подписали ИСР, внимательно с ней не
ознакомившись, то ценность этого инструмента падает.
Необходимо вовлекать заинтересованные стороны проекта в процесс развития и проверки ИСР,
поскольку это приводит к росту их заинтересованности в результатах проекта. Когда
заинтересованные стороны проекта видят, какими должны быть результаты проекта, они
формируют свое понимание, тем самым способствуют развитию проекта. Заинтересованные
стороны проекта не склонны ставить свои подписи под непонятными, высокопарными
формулировками, характеризующими результаты проекта. Чем больше заинтересованных сторон
вовлечены в проект, тем больше критических рекомендаций мы получаем и тем, соответственно,
точнее можно определить масштабы работ.
Требуемый уровень детализации. Основные компоненты ИСР должны быть конкретизированы
настолько, насколько требует от них процесс управления проектом. Необходимо удостовериться в
том, что вы сможете выполнять работу, не выходя из графика, контролируя процесс, даже если
что-то идет не так или выходит из строя. В то же время, хороший менеджер проекта всегда должен
уметь остановиться на определенном уровне детализации и не углубляться в микроскопические
детали, так как это неизбежно приводит к путанице и сложностям в управлении проектом.
Таким образом, трудность состоит в том, чтобы найти золотую середину и сделать ИСР
максимально полезным и практичным. Далеко не все результаты требуют детализации и
«дробления» на более мелкие задачи. Так, в графике распределения работ, описанном выше, пункт
№2 под названием «план», безусловно, требует разъяснения и имеет 3 подпункта, тогда как пункт
№3 «результаты исследования» не требует конкретизации ввиду того, что суть его вполне ясна
заинтересованным сторонам и менеджерам проекта.
Использование подходящего алгоритма нумерации. В ИСР важен не сам алгоритм, а метод,
который поможет унифицировать все задачи и согласованно применять их в проекте. Поэтому
система нумерации может включать словесные формулировки, числовые значения, но главное –
чтобы все названия задач были единообразны. Кроме того, данная система наглядно отображает,
какие категории являются задачами высшего уровня, и какие подзадачи они включают.
Задачи низшего уровня являются компонентами задач высшего уровня. Самое главное, что
необходимо сделать при разработке ИСР, - это быстро просмотреть содержание документа и
удостовериться в том, что задачи нижнего уровня составляют задачи высшего уровня. Соблюдение
данной логики крайне важно. Это поможет определить, насколько согласованы затраты и объем
работ, требуемый для выполнения задач, и соответствуют ли они в свою очередь приоритетам
высшего уровня.
Диапазон работ проекта должен быть определен полностью. Необходимо убедиться в том, что
ИСР охватывает полный перечень работ по проекту. Если частью результата проекта является,
например, выпуск руководства по эксплуатации какого-либо прибора, то следует убедиться, что
задачи по тестированию и тиражированию руководства включены в ИСР. Если эти задачи не
включены в ИСР, то они либо не будут выполнены, либо их добавят в список незапланированных
затрат. Поэтому самой главной опасностью является недоучет ключевых пунктов, а также такие
меры как активное участие команды проекта в развитии проекта, экспертная оценка в целях
всестороннего анализа проектных задач, сверка ИСР с другими документами проекта и т.д.
Результаты, не относящиеся к проекту, не должны включаться в ИСР. Стремление охватить
весь перечень работ по проекту иногда может привести к включению в ИСР результатов, не
имеющих отношение к сути проекта В ИСР включаются только те задачи, выполнение которых
необходимо и достаточно для достижения целей проекта.
Использование категорий управления рисками. Нет ничего хуже, чем оказаться в ситуации,
когда проект идет полным ходом, и неожиданно возникает опасная ситуация, требующая
подключения не предусмотренных в ИСР ресурсов. Включение механизмов управлениям рисками
в структуру ИСР позволит нам быть уверенными в том, что заложены средства, ресурсы и время
для того, чтобы решать непредвиденные проблемы в случае их появления.
Результаты, относящиеся к стадии инициации и окончательного завершения проекта должны быть
включены в ИСР.
Результаты проекта в начальной и завершающей фазе имеют принципиальное значение и должны
быть включены в ИСР. Опасно недооценивать данные категории. В начале проекта важно
контролировать такие процессы, как формирование и обучение команды проекта, подбор офисных
помещений для проекта и т.д. То же самое имеет отношение к этапу завершения проекта. Если не
учитывать правильно результаты на упомянутых этапах, мы рискуем выйти за пределы графика
или не уложиться в бюджет.
Длительность задач на самом нижнем уровне ИСР должна быть не менее 8 и не более 80
часов. Безусловно, это весьма приближенный метод, однако на низшем уровне ИСР необходимо
формулировать задачи, требующие на выполнение не более одной-двух недель. Тем не менее, если
длительность проекта 8 лет, то на выполнение одной из задач может потребоваться значительно
больше двух недель. В то же время, если проект рассчитан на три месяца, вряд ли его
руководитель захочет, чтобы какая-либо из задач решалась в течение 2-х недель. Поэтому
распределение времени – это важный вопрос, который требует учета ИСР.
Определение ответственных лиц. Когда вы определяете ожидаемые результаты проекта,
необходимо также определить сотрудника или группу сотрудников (департамент), ответственных
за их выполнение. Это важно для того, чтобы контролировать статус той или иной задачи в случае,
если возникают какие-либо проблемы.
Измерение результатов проекта. Все задачи проекта должны быть измеряемы для того, чтобы
можно было оценить прогресс в их выполнении. Например, сколько компьютеров было
модернизировано, сколько функций запрограммировано и т.д.
Создание логической основы для оценки работ и затрат. Итак, разработка графика выполнения
работ, а также сметы будет происходить на основе созданной вами ИСР. Каждая задача в ИСР
сформулирована вами таким образом, что нетрудно определить, что потребуется для ее
выполнения, и сколько это будет стоить.
После этапа разработки ИСР необходимо провести ее внедрение. Если вы когда-либо видели ИСР,
то может показаться, что она сильно отличается от той, что мы здесь обсуждали. Очень часто ИСР
создается путем простого перечисления необходимых задач для достижения цели проекта. Следует
перенести акцент с «Что следует создать, чтобы представить результат проекта?» на «Что нам
требуется, чтобы достичь цели?». Заказчик не редко говорит: «Мне все равно, каким образом вы
добиваетесь результата! Добейтесь результата!». Поэтому очень важно выстроить логическую
последовательность задач и определить сотрудников, ответственных за них.
Как правило, ожидаемые результаты нижнего звена обозначаются как «Пакет работ». Когда
лидеры команд берут ответственность за их выполнение, они сами разрабатывают план, или свою
ИСР, и определяют каким способом добиваться его исполнения. Результаты более высокого
уровня обозначаются как «План счетов управления». Они позволяют отследить менеджерам, как
происходит управление расходами проекта, а также является основой для составления итоговых
отчетов.
В итоге, ИСР необходима для того, чтобы:






ясно обозначить содержание работ проекта;
отследить прогресс в развитии проекта, в отношении того, что уже было достигнуто;
служить вспомогательным механизмом для управления графиком и затратами проекта;
стать основой для набора персонала для проекта;
снизить влияние ротации кадров на проект ввиду того, что объем работ четко определен
независимо от каких-либо изменений в составе персонала;
помочь найти компромисс в понимании основной сути проекта.
3. Планирование качества
Ранее мы обсуждали, насколько важны ожидания заинтересованных сторон проекта для успешного
управления проектом. Удовлетворение ожиданий потребителя, предоставляемых в соответствии с
его требованиями, называется качеством. Хорошее руководство проектом подразумевает высокое
качество результата.
Качество имеет ряд измерений, которые должны быть хорошо известны сотрудникам проекта, и
которые должны приниматься во внимание на стадиях планирования и в ходе реализации проекта.
Качество функциональности
Обладает ли результат проекта такой характеристикой как функциональность? Именно этого
требуют клиенты и другие заинтересованные стороны проекта. К примеру, если результатом
проекта является новая строительная технология, может ли она быть применима как в
строительстве одноэтажных зданий, так и двухэтажных?
Надежность. Нельзя назвать надежными телефонную связь или сервер, которые время от времени
прекращают работать. Подобные системы не отвечают нашим ожиданиям относительно такого
понятия, как надежность. Надежность – важнейший параметр качества, которому потребители
уделяют все большее внимание, с тех пор как информационные технологии и телекоммуникация
входят в нашу повседневную жизнь.
Стоимость. Понятие «Совокупная стоимость владения (ТСО)» дает возможность потребителю
учесть сумму прямых и косвенных затрат на приобретаемую систему за период жизненного цикла
последней. Например, если система включает компьютерное оборудование, то клиенту стоит
поинтересоваться какова закупочная цена, сколько будет стоить техническая поддержка системы
на протяжении всего жизненного цикла системы, сколько стоит обучение конечных пользователей
системы, а также стоимость модернизации и эксплуатационных расходов в будущем. Компании,
способные предложить наилучшую цену с учетом ТСО, реализуют свои системы с большим
успехом. Что касается потребителя, то, принимая во внимание ТСО, составление бюджета на
предстоящие годы станет более реалистичным и точным.
Требования конечных пользователей. Это еще один параметр качества, важный для конечных
пользователей. Приходилось ли вам когда-либо искать что-то на веб-сайтах, и в конечном итоге
отказываться от этого, т.к. время, потраченное на поиск, стоит больше, чем найденная в результате
информация? При этом, предыдущие факторы – надежность и стоимость – могут удовлетворять
пользователя. Но, если ему требуется 15 минут, чтобы произвести простейший поиск, переходя из
одного меню в другое, то система не может считаться требуемого качества. Конечный
пользователь играет ключевую роль в оценке качества конечного продукта.
Оценка конечного продукта с точки зрения удовлетворения потребностей. Можно ли считать
проект успешным, если все цели были выполнены в соответствии с требованиями, однако
конечный продукт более не востребован? Доказать ценность конечного продукта и актуальность
его на момент окончания проекта входит в обязанности менеджера проекта. Возможно, для этого
придется провести необходимые исследования, провести ряд встреч с клиентом, с маркетинговым
отделом, а также с экспертами в области потребительского рынка.
4. Оценка объема и стоимости работ
Когда определена общая стоимость работ, не трудно составить смету расходов, требуемую для
проведения работ по созданию конечного продукта. Именно сама работа, а не сроки ее исполнения
определяет стоимость работ. Для многих организаций сделать это затруднительно, т.к. персонал
получает зарплату ежемесячно, а менеджер не планирует и не отслеживает расходы на зарплату.
Однако если представить работу в единицах времени (час), то можно будет провести
сравнительный анализ самих проектов, и решить, какой из проектов заслуживает продолжения.
Сравнение запланированных и реальных затрат на оплату труда помогает нам понять, на сколько
мы близки или далеки от существующего плана. Существует целый ряд затрат, которые следует
принимать во внимание при планировании бюджета проекта.
Прямые затраты относятся непосредственно к проекту. Это расходы, которые несет организация
в связи с тем, что она реализует проект. Чтобы проверить, является ли предполагаемые расходы
прямыми затратами, представьте, что проект более не существует в вашей организации. Если
соответственно отпадет надобность в этих расходах, то их можно считать прямыми.
Косвенные затраты. Существует ряд затрат, которые несет организация, вне зависимости от
количества проектов, реализуемых организацией в данный период времени. Затраты, не связанные
напрямую с проектами, называют косвенными. Это оплата за пользование инфраструктурой,
поддержку персонала и т.д. К примеру, следует производить оплату за отопление, не зависимо от
того, ведет ли организация пять или десять проектов, а может и вовсе не ведет.
Затраты на оплату труда относятся к прямым затратам. Оплачивается труд людей, которые
непосредственно работают в рамках ИСР, а также тех сотрудников проекта, которые оказывают им
поддержку. Например, Координатор проекта несет ответственность за своевременность
выполнения работ, и может не упоминаться в ИСР, однако затраты на его труд относятся к прямым
затратам, т.к. он работает на проект.
Нетрудовые затраты могут производиться на материалы, инструменты, приобретенные или
взятые в лизинг, расходы на проезд к заказчику и т.д. Характер нетрудовых затрат впрямую
зависит от проекта. Строительный проект, например, несет значительные нетрудовые затраты в
виде затрат на оборудование, необходимого для процесса строительства.
Фиксированные затраты не меняют своей величины. К примеру, если было взято оборудование
для испытаний в аренду на один день, а испытания были проведены за 4 часа, то оплата аренды
взимается за целый день.
Накладные расходы (overhead) или другими словами косвенные расходы. Они также называются
«общими и административными» (G&A), или SADA – (sales, advertising, distribution,
administration). Подобные затраты существуют постоянно и не связаны впрямую с каким-либо
отдельным проектом.
Информация о типах затрат приведена здесь для того, чтобы подчеркнуть степень влияния
менеджера проекта на объем затрат. Что касается косвенных затрат, например оплата отопления
или света, сократить их невозможно. Более вероятно повлиять на прямые затраты, например
приглашать не самых высокооплачиваемых консультантов. Итак, степень влияния на затраты
варьируется в зависимости от статьи расходов.
«Сверху – вниз, снизу – вверх» - два принципа разработки проектной сметы
Принцип «сверху – вниз»
Если приступить к составлению сметы, ориентируясь на самый высокий уровень планируемых
результатов, то следует сказать, что этот метод требует меньше времени, однако точность расчетов
будет недостаточной. Специалист, имеющий опыт составления проектной сметы возможно и
сможет выполнить эту работу с большой точностью, однако есть риск того, что будут упущены
некоторые из планируемых результатов.
Принцип оценки стоимости «сверху вниз» (top down estimate) используется для оценки затрат на
более ранних стадиях проекта, а именно в тот момент, когда информация о проекте еще очень
ограниченна. Смысл такой обобщенной экспертной оценки в том, что она производится в общих
чертах, и проект оценивается практически по одному показателю. Оценка удобна тем, что не
требует больших усилий и времени. Недостатком же является не очень высокая точность
оцениваемых затрат, чего можно добиться при использовании принципа «снизу – вверх».
Принцип «снизу – вверх»
Руководствуясь принципом «снизу-вверх», следует начинать с самого нижнего уровня
планируемых результатов, определить объем работ и стоимость по каждому из них. Данный
принцип имеет ряд преимуществ.




Точность оценки выше, т.к. подсчитываются небольшие компоненты проекта.
Использование данного принципа позволяет найти компромисс между требуемыми
сроками, ресурсами и содержанием проекта, т.к. каждый планируемый результат нижнего
уровня в ИСР имеет соответствующую стоимость и сроки выполнения. Допустим, вам
необходимо сократить проектную стоимость на $50 000. Обратитесь к таблице ИСР,
выберите несколько задач, которые могут быть удалены из проекта и в сумме составляют
около $50 000. Итак, руководствуясь принципом «снизу-вверх» мы можем планировать и
управлять проектом с большей точностью и эффективностью.
Сам процесс построения сметы приводит к росту заинтересованности к результатам проекта
у членов команды. Заинтересованность может возрасти еще больше, если сотрудников
попросить самостоятельно поработать над сметой.
В ходе работы над сметой становятся более понятными некоторые моменты, вызывающие
вопросы и опасения. Мы стремимся понять, какие из планируемых результатов были
пропущены, а также правильно представить себе конечные результаты проекта и оценить
их. Принятие согласованной со всеми заинтересованными сторонами проекта сметы, по
какому-либо из планируемых результатов содержит некоторую степень риска, однако,
лучше разрешить все вопросы на этапе составления сметы, чем решать их в ходе
реализации проекта.
Существует ряд сметных методик, которыми можно воспользоваться на этапе оценки проекта.
Методики применимы в обоих подходах к составлению сметы (сверху вниз и снизу вверх). Каждая
методика имеет свои достоинства и недостатки, и менеджер проекта должен сделать выбор в
зависимости от обстоятельств.
Функциональная методика
При использовании данной методики следует в первую очередь определить профессиональные
знания и умения, необходимые для реализации проекта, а также оценить ставки и стоимость работ.
Необходимо определить количество требуемых специалистов, а также решить, как долго они
должны работать в проекте. Умножая количество специалистов на предполагаемые ставки и время
работы в проекте, мы получим сумму предполагаемых затрат на оплату специалистов проекта.
Методика функционального подхода достаточно прямолинейна и не очень точна. Данный подход
не ориентируется на планируемые результаты проекта и не учитывает данные ИСР. Это чисто
функциональный подход, определяющий области знаний, необходимые для выполнения работ по
проекту. В процессе составления сметы есть риск упустить детали, т.к. данный подход не
учитывает все содержание проекта. Мы также лишены возможности увязывать такие величины,
как содержание - стоимость – сроки работ.
Функциональная методика является основой для составления сметы по принципу «сверху вниз» и
имеет характерные ей достоинства и недостатки. Однако профессионал в этой области может
пользоваться данной методикой с удивительной точностью.
Параметрическая методика
Способ параметрической оценки также является разновидностью метода «сверху вниз». Степень
точности данного способа, как правило, сопоставим со степенью точности, получаемой при
использовании метода оценки «по аналогу».
В основе методики параметрической оценки лежит определение того параметра или параметров
проекта, изменение которых приводит к пропорциональному изменению стоимости проекта. В
математическом плане параметрическая модель оценки строится на основе одного или нескольких
параметров. Значения заданных параметров вводятся в модель расчета, в результате чего получают
оценку стоимости проекта.
В тех случаях, когда параметрические модели различных проектов совпадают, и величину затрат и
значения самих параметров легко подсчитать, мы можем повысить степень точности
параметрической оценки. Например, в случае, когда у нас имеются два законченных проекта,
причем стоимость одного из них больше стоимости оцениваемого проекта, а стоимость другого –
меньше, и параметрическая модель справедлива для обоих выполненных проектов, то точность
параметрической оценки стоимости предстоящего проекта и надежность использования параметра
будут достаточно высокими.
Оценку можно производить также с использованием более чем одного параметра. В этом случае
может возникнуть необходимость приписать каждому из параметров, в зависимости от его
значимости, определенный весовой коэффициент, что дает возможность получить наиболее
вероятную оценку стоимости.
Пример. Предположим, строительство площадки для парковки обходится в 115 долларов за
квадратный метр. Следовательно, постройка площадки с общей площадью в 1000 квадратных
метров обойдется в 115 тыс. долларов.
Методика оценки «по аналогу»
Методика оценки «по аналогу» является одной из разновидностей способов оценки «сверху вниз».
Суть ее заключается в том, что для предсказания стоимости оцениваемого проекта используются
фактические данные о стоимости ранее выполненных проектов. В основе этого метода лежит
утверждение, что все проекты в чем-то схожи между собой.
Чем больше сходство между проектом-аналогом и оцениваемым проектом, тем больше
вероятность получения точной оценки.
Например, при разработке программного обеспечения, многие разделы программы, сходные по
объему необходимых трудозатрат достаточно легко просчитать аналоговым методом. Если объем
работ в новом проекте на 50% больше предыдущего, то, используя метод оценки «по аналогу»
можно предположить, что и стоимость нового проекта будет на 50% больше стоимости
предшествующего – естественно, при этом подразумевается, что все остальные составляющие
остаются неизменными.
При сравнении двух аналогичных проектов необходимо составить перечень сходных элементов и
различий, что позволит нам правильно определить сроки исполнения и стоимость нового проекта.
Следует учесть, что в реальной жизни не бывает двух одинаковых проектов. Даже, если при
сравнении, проекты действительно окажутся идентичными, то отличие их будет состоять во
времени их реализации, а это уже подразумевает отличия. Менеджеры, не желающие учитывать
эти различия, могут столкнуться с большими проблемами в ходе реализации проекта.
Информация по всем завершенным проектам в организации должна храниться в базе данных, и
должна быть доступна менеджерам, начинающим новые проекты. Они должны иметь возможность
подбора наиболее схожего проекта.
Техника оценки и анализа программ PERT (Program Evaluation and Review Technique)
Техника оценки и анализа программ (PERT), была разработана в 1958 году по заказу
Подразделения специальных проектов Министерства Обороны США для проекта создания
ракетной системы «Поларис» (Polaris). PERT — это способ анализа задач, необходимых для
выполнения проекта, в особенности, анализа времени, которое требуется для выполнения каждой
отдельной задачи, а также определение минимального необходимого времени для выполнения
всего проекта.
PERT был разработан главным образом для упрощения планирования и составления графиков
больших и сложных проектов. Метод подразумевал наличие неопределённости, давая возможность
разработать рабочий график проекта без точного знания деталей и необходимого времени для всех
его составляющих.
Итак, на выполнение каждого задания должны быть предложены
Минимально-реальные (оптимистические) сроки исполнения каждой из работ проекта
Максимальные (пессимистические) сроки работ
Наиболее вероятные сроки (4)
Уравнение выглядит следующим образом:
min + (4 наиболее вероятных) + max
Оценка по PERT =
6
Используя данную формулу, возможно составить реальный график выполнения задач и определить
длительность проекта в целом. Данная методика имеет отношение и к ресурсам, требуемым для
выполнения задач по проекту.
Определение диапазона требуемых ресурсов
При определении суммы проектной стоимости рекомендуется ставить в известность заказчика о ее
возможных колебаниях. Например, при стоимости проекта в $1 млн. диапазон колебаний может
составить от +$10 000 до +$500 000.
5. Подбор команды
Именно сотрудники определяют успехи или неудачи проекта. Известно, что некоторые
программисты справляются с заданиями в 25 раз быстрее, чем другие, благодаря своему опыту и
мотивации. Правильно подобранный персонал команды проекта является залогом успеха
реализации проекта. Одним из ключевых вопросов управления проектами является регулирование
рабочего времени персонала. Необходимо понять, существуют ли в ходе проекта периоды, в
течение которых не требуется привлечение всех сотрудников на полный рабочий день. Если на
время направлять некоторых сотрудников в другие проекты, то есть риск, что возвращение этих
сотрудников в проект может стать затруднительным по причине загрузки на новом проекте.
Таким образом, самым главным в подборе команды проекта является правильная комплектация
штата сотрудников проекта.
Вторым пунктом является определение графика комплектации кадрового персонала с начала до
окончания проекта. К примеру, если известно, что на второй неделе проекта потребуется привлечь
к работе в проекте большое количество сотрудников, то необходимо понять, сможет ли
организация обеспечить такую потребность в кадрах, а также смогут ли новые сотрудники быть
продуктивными с первого дня.
Не менее значимым является анализ заключительного этапа проекта, т.к. данный период проекта
считается особенно трудным периодом жизненного цикла проекта. Активность персонала
снижается, а члены команды проекта начинают заключать новые контракты на работу в других
проектах. Процесс перевода сотрудников на работу в другие проекты не является столь легким
делом, как это может показаться сначала.
В управлении проектами важно понимать, как будет осуществляться процесс установления
коммуникаций между заинтересованными сторонами проектной работы. Иногда очень сложно
определить разницу между внутренним и внешним (привлеченным) персоналом, поскольку
организация может задействовать временных работников, отдать на аутсорсинг большие объемы
работ и т.д.
Тем не менее, важно придерживаться определенной стратегии, которая поможет определить, в
каких случаях следует задействовать внутренние ресурсы организации, а в каких – внешние.
Далеко не всегда есть необходимость в привлечении сторонних сил, т.к. это может создавать
определенную опасность для компании.
Среди ключевых пунктов стратегии менеджеров проекта можно отметить следующие.
Основной профессиональный профиль организации. Обычно организация определяет для себя
сферы, в которых она хочет добиться наивысшего профессионализма. Их цель – стать лидером в
определенном сегменте рынка или, возможно, стать передовым производителем в сфере
определенной технологии. Поэтому в их интересах поддерживать и обеспечивать развитие
внутреннего опыта, например, в области жилищного строительства или обучения специалистов
заказчика. Может произойти так, что компания, занимаясь сферой задач вашей компетенции,
добьется успеха и однажды станет вашим конкурентом. С этой точки зрения, менеджер проекта
должен понимать, что отдавать на аутсорсинг подобным компаниям задачи, которые могут
способствовать росту их конкурентоспособности, будет нелогичным.
Доступ к внутренним ресурсам. В случае, если для реализации проекта требуемые ресурсы в
нужном объеме или в конкретное время недоступны, то может потребоваться передать некоторые
задания на исполнение сторонним исполнителям. Основным фактором здесь является
приоритетность проекта для организации. Если проект имеет высокую степень приоритетности, то
вероятность задействовать внутренние ресурсы организации выше. Решением этих вопросов
должен лично заниматься менеджер проекта, приложив максимум усилий.
Доступ к внешним ресурсам. С другой стороны, менеджеру проекта необходимо определить,
доступны ли его команде внешние ресурсы. Проведение точной экспертизы в определенном
объеме в установленные сроки и по приемлемой цене должно быть доступно менеджеру с целью
привлечения внешних работников, если таковые понадобятся. Поиск требуемых ресурсов извне
может быть особенно трудным в сфере высоких технологий, поскольку именно здесь необходимы
знания о последних технических и технологических достижениях в мире. Одним из способов
решить подобную проблему является выстраивание стратегии глобального поиска специалистов в
области специальных знаний в определенных странах (например, в Индии можно найти не очень
дорогостоящих, но достаточно квалифицированных программистов). Поэтому поиск и выбор в
пользу определенных аутсорсинговых компаний может иметь место и за пределами страны.
Защита интеллектуальной собственности. При оценке организации необходимости услуг
аутсорсинга крайне важным является вопрос контроля и защиты интеллектуальной собственности
компании. Речь идет не только о патентах, но и применяемых процессах и методологии,
технических ноу-хау, программного обеспечения и комплектующих, которые используются в
проекте, а также знаниях относительно бизнес-коммуникаций, маркетинговых компаний и т.д.
Каждая организация является носителем огромного объема информации, что делает ее уникальной
и конкурентоспособной. Поэтому привлечение внешних организаций к выполнению проектных
работ компании может представлять опасность в плане защиты ее внутренней информации.
6. Способы оценки сроков проекта
После того, как определено содержание проекта, мы можем переходить к составлению графика
работ. Тем самым, мы приступаем к следующему этапу – управлению сроками проекта. На данном
этапе необходимо определить, сколько времени займет реализация проекта и в какие сроки
необходимо решить ту или иную задачу. Это, в свою очередь, определит, когда именно нужно
привлечь те или иные ресурсы и как мы будем контролировать распределение средств проекта.
Стоит отметить, что в управлении сроками приоритетным является определение взаимосвязей
задач проекта и способов их реализации; именно это и влияет в первую очередь на то, как
выстраиваются задачи в календарном плане работ. Данный подход имеет ряд преимуществ.
Во-первых, работа должна определять график, а не наоборот, так как довольно легко разработать
календарный план, который на деле будет расходиться с нашими намерениями.
Во-вторых, данный подход полностью совпадает с инструментами управления проектами, типа
Microsoft Project.
В-третьих, используя данный подход, мы получаем вполне реалистичный график результатов,
менее подверженных изменениям, в отличие от графиков работ, которые являются более гибкими
и определяются другими способами.
Таким образом, процессы управления сроками проекта включают в себя следующие фазы:
1. Определение состава операций – выявление всех плановых операций, которые
необходимо осуществить. Это достигается при помощи таких методов как: декомпозиция,
шаблоны, планирование методом набегающей волны1, экспертная оценка и т.д.
2. Определение взаимосвязей операций включает идентификацию и документирование
логических взаимосвязей между плановыми операциями. Задание последовательности
может быть выполнение при помощи программного обеспечения для управления проектами
или вручную.
3. Оценка ресурсов операций призвана определить, какие ресурсы (человеческие,
материальные и т.д.) будут использоваться и в каком количестве, и когда каждый из этих
ресурсов будет доступен для выполнения проектных решений.
4. Оценка длительности операций задействует информацию о содержании работ плановой
операции, типах требуемых ресурсов, расчетном количестве ресурсов и календарях
ресурсов с указанием их доступности.
5. Разработка расписания осуществляется посредством определения плановых дат начала и
окончания каждой из операций на проекте. Разработка расписания производится
непрерывно по всему проекту по мере выполнения работ, изменения плана управления
проектом и возникновения или прекращения ожидаемых рисков или выявления новых.
6. Управление расписанием интегрирует в себе все вышеописанные фазы и включает в себя:
• Определение текущего состояния расписания проекта;
• Оценка факторов, создающих изменения в расписании;
• Выявление фактов изменения расписания проекта;
• Управление изменениями по мере их возникновения.
1
Метод набегающей волны – вид планирования способом последовательной разработки, при
котором работа, которую надо выполнить в ближайшей перспективе, подробно планируется на
низшем уровне ИСР, а далеко отстоящая по времени работа планируется на сравнительно
высоком уровне ИСР.
Методы разработки календарного плана: диаграмма задач проекта. Метод критического
пути
Диаграмма задач проекта. Первым шагом к составлению диаграммы является определение
взаимосвязи между ожидаемыми результатами, т.е. задачами в ИСР. Нам необходимо узнать,
существует ли последовательность, в которой должны формироваться задачи. Например, следует
ли сначала заложить фундамент дома, а затем начинать строить пол и стены? Представим это
графически следующим образом:
P
→
S
где Р – закладка фундамента, а S – строительство стен и пола
Данные прямоугольники изображают задачи, которые мы определили в ИСР. Стрелка обозначает,
что между двумя задачами существует взаимосвязь. В данном случае, фундамент должен быть
построен прежде, чем приступать к строительству стен и пола. Итак, к каждой из задач нижнего
уровня мы задаем вопрос: «Что следует сделать, прежде, чем приступить к работе по выполнению
данной задачи?» Т.е. нам следует определить предшествующие и последующие задачи. В нашем
случае Р – предшествующая , а S – последующая задача.
Цепочки таких последовательностей мы должны выстроить относительно всех задач в ИСР.
Результат такой работы и будет называться диаграммой задач проекта.
Важно также определить тип взаимосвязи между задачами, которые могут быть следующими.
Жесткая (принудительная) логика. Например, записать информацию на DVD или CD
диск можно только после загрузки диска.
Процедурная (дискретная) логика подразумевает выполнение задач и планируемых
результатов в соответствии с порядком, определенным нашим собственным виденьем.
Искусственная логика. Следует использовать данный тип логики в проектах как можно
реже. Предположим, что у нас есть проект, в котором за какие-то две задачи отвечает один
и тот же сотрудник, скажем, из-за нехватки персонала. В таком случае мы рисуем стрелку
между двумя задачами. Итак, мы строим логику на основании имеющихся ограничений. Но
ситуация может измениться, и в нашем случае, может появиться новый сотрудник в
проекте, который может взять на себя выполнение одной из задач. Поэтому рекомендовано
изначально использовать первые два типа логик, особенно учитывая тот факт, что
изменения в диаграмме могут повлечь множество дополнительных вопросов со стороны
заинтересованных лиц проекта.
По мере формирования задач в диаграмму, необходимо быть уверенным, что каждая задача имеет
одну предшествующую и одну последующую. Взаимосвязь всех задач настолько велика, что
задачи, не имеющие предшествующих и последующих элементов, характеризуют, как
«непредусмотренный разрыв в пути сетевого графика» или «висячая операция».
Взаимосвязь между задачами
Существует 4 типа логических взаимосвязей задач:
Финиш-Старт: (FS) последующая операция может начаться лишь после завершения
предшествующей.
 Финиш-Финиш: (FF) последующая операция не может завершиться до завершения
предшествующей.
Старт-Старт: (SS) последующая операция начинается не раньше начала предшествующей.
 Старт-Финиш: (SF) последующая операция заканчивается не раньше начала
предшествующей.


Во взаимосвязях SS и FF задачи выполняются параллельно, что может быть более эффективно, чем
строить их последовательно. Взаимосвязь задач по типу FS считается наиболее часто
используемой в проектах. Наименее распространенный тип взаимосвязи является SF. Выбор
взаимосвязи задач, применительно к проекту, лежит исключительно на менеджере проекта.
Модификации взаимоотношений между задачами
Следует сказать, что в некоторых случаях между завершением одной задачи и началом другой
должно пройти какое-то время.
Допустим, мы отвечаем за установку компьютерного оборудования. Первой задачей является заказ
этого оборудования, а второй – установка. Доставка оборудования обязательно займет время.
Назовем его «отставание» (Lag). Таким образом, взаимосвязь задач можно обозначить, как FS+2
дня, где «2» подразумевает не ровно два дня, а не менее двух дней. Существует понятие
«опережение» (Lead). Например, мы ожидаем доставку оборудования, которое является новым
страховым продуктом, и принимаем решение начать обучение страховых агентов за 3 дня до
прибытия оборудования. В этом случае, такую взаимосвязь можно обозначить, как FS – 3 дня. Это
означает, что мы начнем обучение не ранее, чем за 3 дня до окончания поставки оборудования, а
может и позже.
Ограничения
Следует также подумать о том, как оптимально составить график планируемых результатов.
Существуют некоторые планируемые результаты, выполнение которых может быть отсрочено, при
этом, не оказывая влияния на окончание самого проекта. Итак, мы устанавливаем срок исполнения
результата, как «как можно дольше» (as-long-as-possible). Таким же образом можно установить
срок «как можно раньше» (as-soon-as-possible). Такие ограничения считаются достаточно
свободными. Результаты некоторых проектов должны быть достигнуты к какому-то
определенному моменту в будущем. Допустим, ко дню проведения демонстрации или к моменту
начала проверки функционирования системы. В таком случае мы устанавливаем сроки «следует
начать в…» или «следует окончить в …». Данные ограничения считаются более жесткими. Кроме
указанных, существуют также следующие ограничения.
Начать не позже, чем …
 Завершить не позже, чем …
 Начать не ранее, чем…
 Завершить не ранее, чем …

Не рекомендуется ставить ограничения по срокам, привязанные к определенной дате. Наиболее
часто используемое ограничение – «как можно раньше».
Составление графика с учетом возможных неудач
В процессе планирования графика работ стоит задуматься о некоторых промежуточных
результатах, которые могут, к примеру, потребовать дополнительные испытания и, вследствие
этого, доработки. Планирование дополнительного времени для подобных случаев следует
проводить в ходе составления общего графика работ. Следует допустить, что промежуточный
результат может иметь различные уровни недостатков: высокий, средний, низкий, или, скажем,
значительный, умеренный, ограниченный. Категории могут быть выбраны в зависимости оттого,
что больше подходит для вашей организации. Затем подумайте, сколько потребуется времени на
каждый уровень недостатков. В основном, здесь следует полагаться на предыдущий опыт ведения
проектов. Несомненно, график будет иметь весьма приближенное значение. В случае если
реализация проекта будет осуществляться успешнее, чем предполагалось, то вы будете опережать
график. Если же наоборот, то стоит подумать, на каких последующих этапах развития проекта
можно будет наверстать упущенное время.
Как пользоваться графиком?
Общий резерв времени. Когда все планируемые результаты отражены на диаграмме, то не трудно
определить начало и окончание каждого результата. На такой диаграмме нас интересуют 4 даты по
каждому из планируемых результатов.
Самая ранняя дата начала выполнения задачи в соответствии с логикой и ограничениями
расписания называется «ранний старт». Ее начало зависит от того, должна ли предшествующая
задача быть завершена или достаточно ее начать. Прибавляя к дате «раннего старта» отрезок
времени, предназначенный на выполнение задачи, мы находим дату «раннего финиша», или
наиболее раннего срока завершения задачи в соответствии с логикой и ограничениями расписания.
Таким образом, мы можем определить ранний старт и финиш для каждой из задач на диаграмме.
Такой метод называется «прямой проход» ( “forward pass”). Он подразумевает прочтение
диаграммы слева направо. Итак, используя метод прямого прохода, мы можем также узнать какова
общая длительность всего проекта, и в какое время нам понадобятся ресурсы для выполнения
проектных задач.
Как не удивительно, но менеджеров проектов иногда интересует, на сколько поздно они могут
завершить некоторые задачи проекта, при этом по срокам не выходя за рамки самого проекта.
Такая информация может, к примеру, потребоваться, когда ресурсы еще не получены. Если
выполнение задачи требует больших капиталовложений, то разумнее отложить ее выполнение на
возможно поздний срок, тем самым минимизировать риск того, что деньги будут потрачены
только на закрытие проекта.
Определив поздний финиш и поздний старт для каждого задания, можно применить метод
«обратного прохода» (backward pass), т.е. прочтение диаграммы справа налево, т.е., мы начинаем с
конца проекта и двигаемся к его началу. Итак, в результате применения этого метода, мы знаем,
каковы крайние сроки начала и окончания задания, при этом, не нарушая общих сроков
реализации проекта.
Таким образом, для любого задания общий резерв = поздний финиш – ранний финиш.
Метод критического пути — эффективный инструмент планирования расписания и управления
сроками проекта.
В основе метода лежит определение наиболее длительной последовательности задач от начала
проекта до его окончания с учетом их взаимосвязи. Задачи, лежащие на критическом пути
("критические задачи ") имеют нулевой резерв времени выполнения и в случае изменения их
длительности изменяются сроки всего проекта. В связи с этим при выполнении проекта
критические задачи требуют более тщательного контроля, в частности, своевременного выявления
проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения
проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так
как при изменении длительности задач некоторые из них могут оказаться на критическом пути.
Количество критических путей, проходящих через проект неограниченно. Следует заметить, что
чем больше критических задач предусмотрено графиком, тем более рискованным считается
проект. Другими словами, чем выше процент планируемых результатов, которые должны быть
завершены точно в срок, тем меньше вероятности, что мы сможем это достичь.
7. Планирование и управление рисками:
идентификация, качественная
и количественная оценка.
Предотвращение рисков
Риск – это возможность появления обстоятельств, обусловливающих неуверенность или
невозможность получения ожидаемых результатов от реализации поставленной цели. Если
ситуация определяется как рискованная, она обладает как минимум двумя характеристиками –
вероятность ее наступления и влияние на проект.
Стоит отметить, что в некотором смысле риск имеет ряд положительных черт. Допустим, мы не
уверенны, на сколько конечный продукт будет надежным. Если результат проекта окажется лучше,
чем мы того ожидали, то это можно расценивать как положительную сторону риска.
В то же время, большинство проектов отличаются высоким темпом и сложностью их выполнения.
Поэтому риск-менеджемент является неотъемлемой частью управления проектами и помогает нам
добиться успеха.
Существует 4 блока управления рисками в проекте.
1. Во-первых, необходимо идентифицировать риск или группу рисков. В данном блоке
необходимо перечислить возможные события и условия, в отношении которых существует
неопределенность, и которые могут повлиять на проект. Это следует сделать сразу после того, как
было определено основное содержание проекта. Существует ряд способов, которые помогают
идентифицировать риски.
Мозговой штурм. Главное в ходе проведения мозгового штурма собрать как можно больше
информации о возможных рисках. В дальнейшем их можно отсортировать, оценить их
корректность и расставить приоритеты. Необходимо собрать как можно больше заинтересованных
сторон проекта для мозгового штурма. Здесь не должно быть критики или обсуждения идей; целью
данной встречи является составление списка потенциальных рисков проекта, и чем их больше, тем
лучше.
Оценка прошлых проектов. Прошлые проекты организации – это кладезь информации, которая
может предостеречь от ошибок. Рекомендуем попытаться назначить встречи с сотрудниками
предыдущих проектов, они могут предоставить неоценимую помощь.
Интервью с экспертами. Необходимо определить и провести интервью с лицами, обладающими
знаниями в технических вопросах проекта, в оценке потенциальной потребительской аудитории, а
также всего, что касается методологии и инструментов развития проекта. Типичными вопросами к
экспертам могут быть следующими: «Какая непредвиденная ситуация, по вашему мнению, может
возникнуть в подобном проекте?», «Какие проблемы вы наблюдали в других аналогичных
проектах?», «Что бы вы рекомендовали изменить в плане проекта?» и т.д.
Оценка тенденций. Дополнительным способом определения рисков проекта является анализ
современных тенденций развития в обществе, в особенности – трендов, которые имеют место в
настоящее время или в ближайшем будущем. Например, если на сегодняшний день рыночные
тенденции идут вразрез с тем, на что нацелен проект, существует риск того, что он окажется
неудачным. Тренды надо оценивать не только с позиции того, что они значат для перспектив
развития проекта, но и понять какие угрозы они несут для него.
2. После того, как произведена идентификация рисков проекта, необходимо приступить ко
второму этапу – количественной оценке вероятности и величины последствий от введения
изменений в проект. Как правило, здесь применяется система рейтинговых оценок в порядке
убывания. Математические подсчеты в риск-менеджменте имеют важное достоинство – они
позволяют количественно определить вероятность и степень влияния группы рисков. Существуют
различные методы количественной оценки вероятности наступления риска, например, опрос или
распределение вероятностей.
Диапазон стоимостных оценок проекта по результатам опроса по рискам
Низкая
Наиболее
вероятная
Высокая
Проектирование
4
6
10
Создание (строительство)
16
20
35
Элемент ИСР
Тестирование
Итог для проекта
11
15
41
23
Опрос по рискам распределяет
оценки по 3 точкам для каждо
элемента ИСР для треугольно
другого несимметричного
распределения.
В этом примере вероятность
завершения проекта в рамках
стандартной оценки стоимости
или ниже относительно невели
Примеры широко используемых вероятностных распределений
На приведенных схемах
горизонтальная ось «Х»
соответствует возможным
значениям времени или
стоимости, а вертикальная
ось «Y» – относительной
вероятности.
3. После того, как составлен рейтинг рисков, проводится качественный анализ рисков. Разрабатывается
которая поможет довершить профиль проекта. Пример составления матрицы вероятности привед
Матрица вероятности и последствий
Вероятность
Благоприятные
возможности
Угрозы
0,90
0,05
0,09
0,18
0,36
0,72
0,72
0,36
0,18
0,09
0,05
0,70
0,04
0,07
0,14
0,28
0,56
0,56
0,28
0,14
0,07
0,04
0,50
0,03
0,05
0,10
0,20
0,40
0,40
0,20
0,10
0,05
0,03
0,30
0,02
0,03
0,06
0,12
0,24
0,24
0,12
0,06
0,03
0,02
0,10
0,01
0,01
0,02
0,04
0,08
0,08
0,04
0,02
0,01
0,01
0,05
0,10
0,20
0,40
0,80
0,80
0,40
0,20
0,10
0,05
Воздействие (по отно
шкале) на исход зада
стоимость, сроки, сод
качество)
Каждому риску в дан
присваивается показа
основании вероятнос
и воздействия на цель
случае его возникнов
На матрице также по
в организации пороги
умеренных и высоких
которые определяют
воздействия риска на
В матрице рисков существуют различные варианты оценки и определения критической ситуации.
Среди них:
Принятие риска. В данном случае вероятность и влияние риска на проект таковы, что мы
готовы к его наступлению.
Минимизация риска. Здесь подразумевается осуществление ряда шагов, которые
необходимо предпринять, чтобы снизить вероятность наступления риска или уменьшить
его влияние в случае наступления. Данный подход еще именуется как «политика
сдерживания». Применяя данный подход, необходимо внести также изменения в ИСР
проекта.
Перенос риска. Передача риска означает, что мы перекладываем вопрос по решению
рисков на других лиц, которые в свою очередь будут ответственны за их преодоление.
Избежание риска. В данном случае имеется в виду, что проектная команда уклоняется от
наступления риска как такового. Избежание риска, как правило, означает, что руководители
проекта выбирают иной путь его развития, чтобы не допустить его появление.
4. В качестве 4-го блока риск-менеджмента обозначается мониторинг проекта и внедрения
соответствующих решений в случае наступления чрезвычайной ситуации. Основным
инструментом управления рисками является их предотвращение, что, как правило, означает
применение мер по минимизации рисков или по снижению их воздействия на проект. Их следует
обязательно включить в вашу ИСР, поскольку в таком случае на них будет выделено время,
средства и ресурсы для их реализации.
Помимо мер предотвращения риска, в качестве основных инструментов и методов управления
рисками стоит выделить:
Пересмотр рисков. Часто в процессе мониторинга рисков возникает потребность в их
пересмотре определении новых угроз проекта, которых может не оказаться в реестре
плановых мероприятий по реагированию. Поэтому требуется дополнительное планирование
по предотвращению новых рисков.
Аудит рисков подразумевает изучение и документальное оформление результатов оценки
эффективности мероприятий риск-менеджмента.
Анализ отклонений и трендов включает прогноз потенциальных отклонений проекта на
момент его завершения по показателям стоимости и расписания. Отклонения от основного
плана указывают на последствия, вызванные угрозами или, напротив, благоприятными
возможностями.
Техническое измерение исполнения – это сравнение технических результатов,
полученных в процессе реализации проекта, с запланированными.
Анализ резервов – это сравнение объемов оставшихся резервов на непредвиденные
обстоятельства с количеством оставшихся рисков по состоянию на любой момент времени
процесса выполнения проекта.
Совещания по текущему состоянию.
Управление рисками может стать одним из ключевых пунктов повестки дня периодических
совещаний. Проведение диалога по вопросам риск-менеджемента облегчает процесс управления и
предотвращения рисков, делая его более эффективным и точным.
8. Как принимать решения об аутсорсинге.
Виды контрактов
Как правило, аутсорсинг обозначает передачу организацией определённых производственных
функций на обслуживание другой компании, специализирующейся в соответствующей области.
Это может быть, например, справочная служба, проведение тренингов или производство какойлибо продукции.
Если в сферу вашей компетенции входит работа с однотипными проектами, одним из способов их
структурирования в плане развития и накопления внутреннего опыта и навыков и привлечения
организаций извне является создание ядра команды внутри фирмы при поддержке внешних
ресурсов, если таковые потребуются.
Сложность в управлении проектом заключается в том, что штатный план невозможно определить
сразу для всех его этапов, ведь в начале проекта неизвестно, понадобится ли на этапе его
завершения помощь внешних организаций. Это является весомым аргументом в пользу разделения
этапов проекта на подэтапы, которые в свою очередь можно планировать. Таким образом, на этапе
анализа проекта или раньше можно понять, будет ли команда проекта самостоятельно заниматься
той или иной задачей или отдаст ее на аутсорсинг.
Кроме того, набор навыков, который требуется для выполнения той или иной задачи, не всегда
совпадает с тем, что Вы собираетесь купить или интегрировать в проект. На сегодняшний день всё
больше организаций, приступающих к разработке и реализации проекта, обращаются к помощи
консалтинговых агентств. Консультанты приглашаются не просто для того, чтобы осуществить то,
что было определено заранее. От них ожидаются решения конкретных задач и внесения изменений
и рекомендаций по проекту.
Существует ряд критериев, которых стоит придерживаться при выборе консалтингового
агентства:
Мотивация
Здесь имеется в виду, насколько консалтинговая фирма заинтересована в том, чтобы заключить с
нами контракт. С другой стороны консультанты должны убедить нас в преимуществах
использовании их методологии при выполнении задач проекта.
Корпоративная культура организации
Каждая организация характеризуется собственной историей развития и особым подходом к бизнес
- процессам. Поэтому при заключении контракта с консалтинговым агентством важно уяснить,
совпадают ли цели и ценности данной организации с приоритетами компании-заказчика. Как
правило, организация имеет налаженные контакты с фирмами, к которым она обращалась ранее.
Как следствие, может сохраниться информация, которая поможет понять стоит ли заключать
контракт с этой фирмой вновь. Очень важно понять, какая атмосфера царит в данной компании,
поскольку работать с ней предстоит сотрудникам вашей компании.
Методология
Все организации имеют собственную методологию развития бизнеса, с помощью которой
создаются новые продукты и происходит процесс управления проектами. Вам как руководителю
проекта важно понять, насколько методология выбранной вами консалтинговой компании
согласуется с вашей.
Достигнутые результаты
Запросите у консалтинговых фирм рекомендательные письма, копии документов по проделанной
работе. Выясните, сколько времени данная компания затратила в прошлом на задачи, сходные с
теми, над которыми работаете вы. Необходимо акцентировать внимание на результатах
выполненных ими работ в прошлом, а не на том, что они готовы предоставить вам в будущем.
Технические навыки
Значимость технических навыков консалтингового агентства будет зависеть от того, какова
основная цель проекта. Если его главной задачей выступает изменение методологии, достаточно,
чтобы нанятые консультанты были формально знакомы с технологиями в области
промышленности, которой вы работаете. С другой стороны, если требуется активное участие
консультантов на техническом уровне, в таком случае технические навыки будут для вас иметь
первостепенную важность.
Стабильность
Многие консалтинговые фирмы имеют непродолжительный срок существования. Важно понять,
какова вероятность того, что данная организация будет сотрудничать с вами до конца проекта.
Кроме того, может ли фирма гарантировать вам, что ее сотрудники будут с вами работать до
окончания проекта. Обеспечит ли данная фирма передачу опыта от старых сотрудников новым,
если произойдет замена кадров.
Авторитетность
Вам как менеджеру проекта необходимо понять, каков стиль работы, и какова репутация
консалтинговой компании, услугами которой вы собираетесь воспользоваться относительно
защиты активов своих клиентов. Если фирма пользуется репутацией агрессивного игрока, скорее
всего, не стоит обращаться к ее помощи. Кроме того, если вы решитесь привлечь данную фирму к
работе над проектом, то вам придется передавать ей много проектной информации. Будьте
уверенны, что подобная информация будет использована фирмой по назначению.
Новизна рекомендаций
Вам стоит обсудить с внешними консультантами, насколько оригинальны решения, которые они
собираются Вам предложить. Если возможно, сравните ряд работ, сделанных данной фирмой
ранее, и сделайте вывод, насколько различны подходы и рекомендации каждой из них. Если в
каждом проекте виден нестандартный подход к решению конкретной ситуации, с таким клиентом
есть смысл заключать контракт.
Перед тем, как внешние консультанты приступят к реализации проекта, необходимо утвердить и
согласовать методологию планирования работы и удостовериться в том, что члены проекта
знакомы друг с другом и понимают свою роль и ответственность в нем.
Существует ряд действий, которые помогут вам держать ситуацию под контролем, а
также заложить прочный фундамент для успешной реализации проекта:
Установить открытые взаимоотношения в коллективе
В начале планирования определите с консультантами контактных лиц, через которых будут
проходит каналы коммуникации. Контроль коммуникаций в начале проекта поможет
предотвратить ситуации, выходящие за рамки предполагаемого.
Составить перспективную оценку проекта
В контексте планирования проекта перспективный анализ проекта является детальным описанием
каждого этапа работ, какие задачи должны быть включены и выполнены. Имеет смысл провести
обсуждение на эту тему на начальном этапе планирования.
Заранее вовлечь все заинтересованные стороны проекта
Ваша задача состоит в том, чтобы как можно раньше задействовать все заинтересованные стороны
проекта, с тем, чтобы они стали активными участниками процесса планирования.
Разделить проект на логические части
Если Вы задумали осуществить крупный проект, например, в области интеграции систем или
строительный проект, необходимо составить генеральный план и уточняющие планы. Генплан
объединяет в себе планы нижнего уровня, ответственными за которые являются руководители
технических отделов или менеджеры проектов. Если выполнение некоторых из задач плана
поручается другим организациям, то вы должны быть уверены, что каждая организация составила
план выполнения задания. Следует подумать о том, каким образом вы собираетесь контролировать
выполнение этих задач.
Структурировать организацию
Генеральный план и содержание проекта могут стать основой для составления схемы
организационной структуры проекта. В проекте могут быть несколько менеджеров – по одному из
каждой организации, а может быть один главный руководитель проекта, которому подчиняются
руководители подпроектов.
Если планируется крупномасштабный проект, то необходимо назначить административного
помощника, который будет координировать всю работу. Это важно, поскольку руководитель
проекта сам не может постоянно осуществлять ввод данных, а также выполнять
административную работу, необходимую для реализации плана.
Отрегулировать механизм контроля в проекте
На этапе планирования необходимо определить, каким образом будет осуществляться мониторинг
развития проекта. Стоит также осуществлять перепроверки и не перекладывать ответственность по
контролю за проектом на внешних консультантов, которые занимаются его развитием.
Организация подрядных работ
По мере того, как все большее число работ отдается на аутсорсинг, руководителю проекта
приходится все чаще заключать юридические контракты со сторонними фирмами. Безусловно,
организация работ на условиях подряда имеет ряд достоинств.
Во-первых, работа на таких условиях, как правило, выполняется значительно быстрее, т.к.
управлять всем объемом работ по проекту, используя внутренние ресурсы организации, которые
уже используются в других действующих проектах значительно сложнее. Таким образом,
благодаря привлечению фирм для выполнения проектных работ на условиях аутсорсинга можно
эффективнее добиться цели проекта. Для того, чтобы получить максимум пользы от аутсорсинга,
необходимо четко осознавать цель проекта с тем, чтобы направить имеющиеся в распоряжении
ресурсы на реализацию правильно сформулированной задачи.
Во-вторых, при заключении договоров подряда можно быстро распустить проектную команду в
случае, если организация больше не заинтересована в продолжении проекта. В то же время, для
того, чтобы эффективно пользоваться аутсорсингом в проектной деятельности, руководитель
проекта должен быть как минимум знаком с основными понятиями в сфере организации
подрядных работ. Итак, основными видами контрактов являются:
1. Контракт с возмещением затрат плюс фиксированное вознаграждение (Cost Plus Fixed Fee
(CPFF) Contract)
По этому типу контракта покупатель возмещает поставщику оговоренные затраты, которые
определяются условиями договора и уплачивает фиксированную сумму дохода в качестве
вознаграждения.
2. Контракт с возмещением затрат плюс премия за результаты (Cost Plus Incentive Fee
(CPIF) Contract)
По этому типу контракта покупатель возмещают поставщику оговоренные затраты, которые
определяются условиями договора. При этом поставщик получает дополнительный доход
при выполнении установленных критериев исполнения работы. В отличие от предыдущего
вида контракта, у поставщика имеется более высокая мотивация к выполнению целей
осуществления работ, которые приносят выгоду подрядной организации.
3. Контракт с твердой фиксированной ценой (ФЦ)
(Firm Fixed-Price (FFP) Contract)
Тип контракта, когда заказчик платит поставщику фиксированную сумму в соответствии с
условиями контракта, вне зависимости от затрат поставщика. При подписании данного вида
контракта стимулирующим фактором для заказчика является ограничение расходов с целью
получения большей прибыли от выполнения работ.
4. Контракт с фиксированной стоимостью и премией за результаты (ФС+П)
(Fixed-Price Incentive Fee (FPIF) Contract)
Данный тип контракта также подразумевает выплату заказчиком поставщику
фиксированную сумму в соответствии с условиями контракта. В то же время, если
поставщик выполнил все оговоренные критерии подрядной работы, заказчик обязан
выплатить ему дополнительную сумму, т.е. премию за результаты. Для поставщика это
является стимулом к тому, чтобы превзойти ожидаемые результаты и, кроме того,
сдерживать свои расходы, поскольку по условиям фиксированного контракта заказчик их
не возместит.
5. Контракт с оплатой стоимости затрат рабочего времени и материалов (Time & Materials
(T&M) )
В некоторых случаях организация заключает с поставщиком договор, согласно которому
подрядчику выплачивается фиксированная сумма за результат выполненных работ, а также
возмещаются фактические затраты, имевшие место вовремя осуществления заказа по
проекту. Ставка заработной платы рассчитывается на почасовой основе и включает
прибыль.
Данный вид контракта является выгодным в том случае, когда неясен диапазон показателей
результативности, например, при проведении исследовательских или испытательных работ.
Таким образом, сделав выбор (как правило, с помощью юриста организации) в пользу того или
иного вида контракта, поставщик товаров и услуг получает стимул к выполнению оговоренного
круга задач, что обеспечивает достижение целей подрядной организации и проекта в целом. Это, в
свою очередь, позволяет руководителю быть более уверенным в успехе проекта.
9. Результаты этапа планирования
Организация, которая стремится к успешному планированию проектов, должна придерживаться следу
1. Рекомендуется постоянно соотносить технические условия с требованиями к проекту, а также учитыва
клиентов.
2. Сметы составляются на ранних стадиях проекта, на пример в фазе анализа и планирования. После заверш
разрабатывается смета на проведение оставшихся работ.
3. Сметы составляются с учетом как максимальных, так и минимальных сумм.
4. Окончание проекта должно быть четко сформулировано в плане. В начальных стадиях планировани
изложено, каким образом будет осуществлен переход к вводу в эксплуатацию и техническая под
5. Для проектов длительной реализации рекомендовано периодически проводить перепланирование для тог
большего соответствия на более поздних этапах проекта.
6. Не стоит пренебрегать альтернативными предложениями. В случае изменения условий можно будет ими
7. Сметы должны ориентироваться на график работ, объем резервов, а также рекомендации относительно т
можно сформировать резерв.
8. Имеющиеся ресурсы могут влиять на запросы, а их оценка должна быть включена в пла
9. Планируемые результаты или задачи по ИСР должны быть сформулированы понятно, и представ
самостоятельные части работы.
10. ИСР должна охватывать весь объем проекта, включая задачи, необходимые для начала и закрыт
11. Работа, которая будет выполняться в рамках проекта должна подразделяться на несколько уровней, сф
принципах:
ценности для проекта,
существующего риска
методике руководства проектом
12. Глоссарий ИСР должен содержать дополнительную информацию, необходимую для понимания содержа
13. Обзоры проектного плана, а также информация по другим важным для проекта темам должны храниться
14. План снижения рисков должен быть составлен, а также быть актуальным.
15. Проект должен управляться, руководствуясь концепцией “phase and gates process” – то есть, на каждом э
должны быть установлены регулирующие механизмы, позволяющие перейти к следующему этапу только по
закончены все работы на предыдущем Входные и выходные данные для каждого компонента должны быть
правильно определены.
16. Накануне значимых событий, проводимых проектом, следует подготовить обзоры о готовности проекта
17. Резервный план и план по восстановлению в случае утери части результатов в какой-либо из стадий про
подготовлены.
18. В процессе управления изменениями используется документация по ключевым шагам процесса
19. Должна быть сформирована комиссия по управлению изменениями. Собрания членов комиссии проводя
необходимости с целью своевременной подготовки обзоров о запросах на предстоящие изменения, а также о
на проведение текущих изменений.
20. Документ, содержащий информацию о масштабах, сроках и видах затрат проекта должен быть одобрен в
заинтересованными лицами.
21. В архиве данных должна содержаться информация о проведенных расчетах, а также другая аналогичная
целью использования в ходе планирования последующих проектов.
22. С целью проведения расчетов следует использовать надежные методики, при этом все стейкхолдеры дол
наиболее точными.
23. График проекта, план по ресурсам и общий бюджет проекта должны быть основаны на сетевых графика
имеющих единый стартовый отсчет и завершение.
24. Значимые этапы проекта (как возможные проявления риска) должны регулярно фиксироваться в отчетах
едином формате
25. По возможности, запросы на внесение изменений рекомендуется рассматривать в рамках последующего
рамках текущего проекта, тем самым, затягивая его на неопределенное время.
26. Графики и бюджетные сметы не следует строить, рассчитывая обязательно на благоприятный исход. Луч
Технику оценки и анализа программ PERT или другие аналогичные методики.
4. Выполнение работ и общий контроль
1. Приоритезация задач по степени критичности
2. Периодическая переоценка рисков
и их предотвращение
3. Управление командой
4. Распределение информации по категориям
для всех лиц, заинтересованных в проекте
5. Способы тестирования продукта
6. Оценка проделанной работы: метод
освоенного объема (Earned Value Technique)
7. Результаты этапа выполнения работ и контроля
1. Приоритезация задач по степени критичности
После того, как утвержден первоначальный план проекта, необходимо приступить к
реализации планируемых мероприятий. В действительности, вся текущая работа
менеджера проекта характеризуется только одним: идет ли работа по плану? Однако ни
предшествующую, ни последующую деятельность проекта невозможно правильно
оценить без учета информации, получаемой по ходу проекта от всех заинтересованных
сторон. Рассмотрим несколько факторов, способствующих наилучшим образом
получить информацию о развитии проекта.
Частота обновлений статуса проекта
Необходимо в первую очередь ответить на вопрос - как часто стоит проводить
обновления статуса – ежедневно, еженедельно или ежемесячно? Это позволит оценить
важность проекта для организации, степень риска его дальнейшего проведения,
надежность данных, предоставляемых лицами, ответственными за модернизацию, а
также определить уровень требуемой детализации плана.
Содержание обновлений
Время, выделенное на определение содержания проекта, следует расходовать
рационально. В ходе обсуждения, общее понимание статуса проекта и актуализация
проекта происходят по мере предоставления членами команды новой информации.
Менеджер проекта, к примеру, может выделить каждому сотруднику по 15 минут для
краткого отчета о проделанной работе, а именно:
 Количество потраченных часов;
Объем выполненной работы в процентах;
 Оставшееся количество часов;
 Статус идентифицированных рисков;
 Выявление новых рисков;
 Факторы, сдерживающие развитие проекта;
 Реальная дата начала работы над проектной задачей;
 Ожидаемая дата завершения выполнения задач(и).

Уровень детализации
Определение уровня детализации проекта является необходимым элементом этапов
планирования, выполнения и контроля проекта. Когда задачи по проекту исполняются
активно, то данные по результатам их завершения должны быть представлены так, как
они были определены в плане. Поэтому очень важно контролировать процесс
выполнения задач в строгом соответствии с ИСР.
Лица, ответственные за проведение обновлений
Очень важно заранее определить круг лиц, ответственных за предоставление
информации о статусе проекта. Если для непосредственно персонала проекта данный
вопрос может быть вполне ясен, то задача усложняется, если проект ведется совместно с
другой компанией. Поэтому необходимо четко обозначить круг лиц фирмы-поставщика,
которые будут предоставлять данные по проектным работам на постоянной основе в
течение всего проекта.
Формат данных
Зачастую данные по результатам проектных задач предоставляются в различных
форматах. Поэтому руководителям проекта, осуществляющим контроль за ходом его
выполнения, стоит распространить между всеми рабочими группами образец
оформления отчета. Это весьма облегчит анализ результатов деятельности и
определение статуса проекта.
Метод предоставления информации
Активное использование средств Интернета и Web-данных является на сегодняшний
день одним из ключевых методов сбора и агрегирования информации от различных
проектных команд о статусе выполняемых ими задач. Кроме того, электронная база
данных по проекту позволяет получить информацию в режиме реального времени. В то
же время, чем чаще проводится обновление и детализация заданий проекта, тем больше
времени и средств необходимо выделять для их осуществления и контроля. Поэтому
необходимо заранее планировать все этапы получения отчетов и обновления
информации по проекту.
Обновление плана. Как правило, план проекта может корректироваться. С точки зрения
графика работ и затрат на их выполнение следует рассматривать 3 категории,
применяемые в процессе управления плановыми изменениями. Среди них:
Базовый план – Изначальная версия плана;
Фактические показатели – данные по объемам затраченных средств на
осуществление проектных работ на настоящий момент;
Текущий план – пересмотренный и уточненный план, основанный на результатах
проекта к настоящему времени и событиях, планируемых в ближайшем будущем.
Фактические данные и любые изменения по проекту могут быть включены в текущий
план, тогда как базовый план проекта должен остаться неизменным за исключением тех
случаев, когда возникают события, существенно меняющие первоначальное содержание
проекта.
Безусловно, когда базовый план регулярно пересматривается, регистрируемые
колебания в развитии проекта падают до нуля и внешне все идет строго по графику.
Поэтому не редко на менеджеров проекта и руководителей рабочих групп оказывают
давление с целью изменения базового плана, что вынуждает их сталкиваться с
необходимостью противостоять подобным натискам.
В процессе решения задач проекта руководители нередко подходят к своим коллегам и
задают им вопросы касательно хода развития проекта. Возможно, кому-то это покажется
не более, чем желание завязать разговор. Однако, задавая вопросы, типа: «Как успехи?»,
менеджер проекта ведет постоянный мониторинг статуса конкретных задач. Поэтому,
как правило, мониторинг осуществляется постоянно, на неформальной основе и
концентрируется на подзадачах проекта.
В то же время, одного только мониторинга бывает недостаточно. Для того, чтобы
составить полную картину того, что происходит в проекте на данный момент требуется
тщательная оценка полученных результатов и их сравнение с базовым планом проекта.
2. Периодическая переоценка рисков
и их предотвращение
По мере развития проекта, менеджер контролирует процесс реализации проектных
задач, оценивает факторы внешней среды организации и анализирует текущую
ситуацию с рисками, идентифицированными на этапе планирования проекта.
Как правило, периодическая оценка риска представляет собой обновление рейтинга,
который отображает оценку вероятности наступления риска и степени его влияния на
проект, в случае наступления. Поэтому постоянное наблюдение за ходом работ и
составление прогнозов развития предстоящих мероприятий по проекту является
неотъемлемой чертой риск-менеджмента.
Наступление или вероятность наступления риска является главной опасностью для
менеджера проекта. С целью предотвращения риска он должен принять ряд мер.
1. Изучить риск и определить изменения в его содержании по сравнению с тем,
каким он был обозначен на этапе планирования проекта;
2. Рассмотреть стратегию, которая была выбрана для предотвращения данного
риска. Здесь необходимо понять, готовы ли мы принять риск самостоятельно или
переложить его на плечи других партнеров проекта, а также включили ли мы
задачи по минимизации возможных последствий возникновения риска в ИСР?
3. Если мы готовы принять риск и есть большая вероятность, что он случится, то
необходимо активировать резервы проекта, в том числе резервы расходов,
графика мероприятий и т.д. Рекомендации по использованию резервов были
расписаны на начальном этапе проекта. Поэтому сейчас требуется решить вопрос
с тем, использовать ли резервы, заложенные в списке задач, или привлечь
дополнительные внешние ресурсы.
4. В случае использования резервов проекта часть времени и средств, заложенных
в плановом графике, тратится на предотвращение риска. В таком случае,
менеджер проекта не требует привлекать внутренние средства организации,
поскольку в бюджете проекта были заложены средства на случай возникновения
непредвиденных обстоятельств.
5. Если в проекте возникла опасная ситуация, которую предвидели и определили
круг задач для ее решения, сейчас самое время пересмотреть методы и понять,
смогут ли они сейчас снизить вероятность негативных последствий риска.
6. Если руководители проекта определили стратегию таким образом, что
ответственность за риск несет другая организация, необходимо удостовериться в
том, что данное соглашение все еще в силе. Если механизм передачи рисков
несовершенен, есть вероятность того, что решать эти проблемы придется вам
самим. Поэтому необходимо переформулировать стратегию и определить, кто
будет заниматься предотвращением рисков. Новые риски, ранее не
идентифицированные в процессе планирования проекта, могут возникнуть
совершенно неожиданно, в силу сложившихся условий внешней среды, запросов
на внесение изменений в проект и даже внедренных методов по предотвращению
рисков, повлекших за собой новые непредвиденные угрозы. Как правило,
наиболее распространенным методом отслеживания последних изменений
является обновление баз данных по возможным угрозам проекта. Риски,
способные повлиять на состояние проекта необходимо отслеживать и
документировать на постоянной основе, или по мере того, как становится
известно о возможных новых рисках.
Угроза (проблема, чрезвычайная ситуация) – это событие, появление которого угрожает
плану проекта, а также процессам распределения средств, времени и системы качества
продукции. В отличие от рисков, которые могут произойти в будущем, угрозы
существуют здесь и сейчас. Каждая угроза должна быть документально зафиксирована,
что, как правило, означает присвоение ей идентификационного номера.
В то же время угрозы тесно связаны с рисками. Иными словами, угроза может повлечь за
собой возникновение одного или нескольких рисков. Если угроза не решена сейчас, то в
будущем могут возникнуть последствия пренебрежения ею.
Одной из возможных причин появления новых рисков могут стать изменения в
установленном порядке разработки проекта, т.н. «критический путь» или «цепочка» графический вид работ, критичных для выполнения проекта. По мере того, как одни
задания откладываются на более поздний срок, а другие - добавляются, меняется логика
развития проекта и график критических работ. Поэтому необходимо произвести оценку
нового порядка разработки проекта и гарантировать соблюдение графика с учетом новой
«критической цепочки».
Как правило, на менеджера проекта ложится ответственность за оценку результатов и
рациональное управление ими. Это и есть основа постоянного процесса управления и
оценивания рисков. Пример управления угрозами и рисками проекта приведен в
нижеприведенной таблице.
Пример управления угрозами и рисками проекта
Угроза
Недостаточное
количество ПК
для поддержки
системы
регрессивного
тестирования.
Требуется 3
дополнительных
ПК.
Рабочий
план
Взять в
аренду
оборудование
в компании
«EZ Rent»
Сопряженные
риски
1. Продление
периода
тестирования
потребует
дополнительного
финансирования на
приобретение ПК,
что может вызвать
перерасход
бюджета
Ранжирование
риска
Вероятность:
Средняя
Влияние:
Среднее
2. В арендованных
ПК отсутствует
должная
конфигурация, что
задерживает
начало их работы.
Вероятность :
Высокая
Влияние:
Среднее
Рискменеджмент
Принятие
риска
– выделить
достаточное
количество
резервных
средств для
покрытия
переизбытка
бюджета
Минимизация
риска
– отправить по
факсу
требования к
конфигурации
ПК в «EZ Rent».
- подтвердить
немедленное
выполнение
задачи после ее
получения.
3. Управление командой
Вероятность достижения успешного окончания проекта значительно снижается, если у
членов команды отсутствует мотивация к достижению целей. Как следствие, задачи не
выполняются, имеет место текучка кадров, и проект длится до бесконечности. Поэтому
одной из ключевых функций менеджера проекта является поддержание высокого уровня
мотивации своих сотрудников.
Признаками низкого морального духа членов команды являются:


Низкий уровень культуры взаимоотношений между членами команды;
 Неудовлетворительное качество выполнения задач;
 Низкая степень ответственности за результат выполняемых задач;
 Частые отсутствия на рабочем месте по необъясненным причинам;
 Сомнения относительно принимаемых решений;
 Распространение слухов, злословие;
 Неприемлемый стиль работы;
Незаинтересованность в достижении будущих целей развития персонала и
проекта в целом.
Менеджеру проекта как руководителю команды необходимо понять, как и почему
возникают симптомы демотивации его сотрудников. При решении он может
руководствоваться принципами т.н. комплексной системы управления качеством,
сокращенно – TQM (Total Quality Management). Целью данной системы является
постоянное совершенствование процессов производства посредством всестороннего
изучения и анализа данных проекта по всем источникам поступления информации.
Если симптомы распространяются повсеместно, то имеет смысл проводить встречи
менеджера со всеми членами команды. Если же конфликт локализуется между двумя
участниками, достаточно провести индивидуальную беседу и понять суть проблемы.
Недавние исследования, проведенные с участием некоторых руководителей и
работников, выявили наличие демотивационных факторов работы в проекте, в том
числе:
 Лидерские качества менеджера проекта;
Взаимоотношения членов команды с менеджером проекта;
 Заработная плата;
 Гарантия занятости;
 Условия работы;
Взаимоотношения с другими членами команды и коллегами по проекту.


В то же время, имеют место и другие, более специфичные для проектной работы,
демотивационные факторы, такие как:
Неспособность завершить до конца выполнение определенных задач;
 Отсутствие стимула к выполнению задач;
Решения, принимаемые за рамками проекта и являющиеся безосновательными.
Паузы и увеличение рабочей нагрузки из-за необходимости исполнения других
обязанностей.
 Недостаточный объем ресурсов для реализации проекта;
 Частые изменения в содержании проекта.



Помимо всего вышесказанного, стоит отметить важность такого показателя, как кривая
обучения, характеризующая постепенный процесс приобретения опыта и навыков при
поступлении на работу или получением нового задания. Для того чтобы снизить влияние
кривой обучения на эффективность проектной работы, необходимо:
Нанимать наиболее квалифицированных специалистов;
Включать показатели кривой обучения в оценки прогнозов;
Составить документ, доступно рассказывающий о проекте
Разработать план проведения тренингов.
Таким образом, управление командой проекта включает в себя контроль за
деятельностью членов команды проекта, обеспечение обратной связи, решение проблем
и координацию изменений, направленных на повышение эффективности исполнения
проекта.
Если члены команды подотчетны одновременно функциональному руководителю и
менеджеру проекта в рамках одной матричной структуры организации, ее управление
значительно усложняется. Поэтому важным фактором успеха при двойной
подотчетности является обеспечение эффективного управления менеджером проекта.
Перед тем, как непосредственно приступить к управлению командой проекта,
необходимо предпринять ряд шагов, на основании которых будет вестись контроль
работы персонала. Среди них:
1. Обеспечить руководителям команды проекта возможность организации
торжественных корпоративных мероприятий, награждения похвальными
грамотами отличившихся членов команды, упоминания их заслуг в
корпоративных информационных бюллетенях, а также возможность начисления
премий с целью поощрения и повышения мотивации сотрудников проекта.
2. Составить список членов команды проекта, деятельность которых оценивается
в рамках процесса мониторинга и управления.
3. Распределить роли и ответственность между членами команды для адекватной
оценки выполняемой каждым из них работы.
4. Составить план управления обеспечением проекта персоналом. Здесь
необходимо зафиксировать, на какой срок нанимается в проект тот или иной
сотрудник, а также внести информацию по обучению персонала, требованиям
сертификации и соответствиям нормативным документам.
5. Составить официальную и неофициальную оценку эффективности текущей
работы команды проекта, на основании которых могут приниматься меры по
решению проблем и конфликтных ситуаций, улучшению методов коммуникации
и укреплению взаимодействия членов команды.
6. Отслеживать результаты выполнения проекта в таких вопросах, как:
управление расписанием, управление стоимостью, контроль качества,
подтверждение содержания и аудит поставок. Данная информация о прошлых и
прогнозируемых результатах работы команды поможет составить ряд требований
к будущему персоналу проекта, а также создать систему признания заслуг и
поощрений и обновить план управления обеспечением проекта персоналом.
В процессе управления командой проекта менеджер может и должен применять
различные инструменты и методы контроля. Одним из проверенных методов управления
командой является наблюдение и обсуждение процессов выполнения работ и
настроений, царящих среди членов команды. Помимо этого, необходимо также
производить качественную оценку эффективности проекта. Члены команды могут
также получать информацию, касающуюся оценки их работ от тех, кто непосредственно
взаимодействует с ними на условиях обратной связи в 360 градусов. Метод «360
градусов» означает, что исполнитель работ получает оценочные данные о своей работе
из различных источников.
Повышению производительности труда и укреплению позитивных взаимоотношений в
команде способствует эффективное урегулирование конфликтов. Данный метод
управления командой проекта важно применять на ранней стадии, индивидуально с
каждой из сторон. Если конфликт переходит в деструктивную стадию, то для его
решения могут потребоваться формальные процедуры, в том числе меры
дисциплинарного воздействия.
Если количество проблем растет в геометрической прогрессии, то следует завести
журнал регистрации проблем, где необходимо документально оформить и
зафиксировать конкретных людей, в обязанности которых входит решение
определенных проблем к определенному сроку. Это сделает процесс управления
командой более организованным и позволит устранить препятствия, мешающие
достижению поставленных целей.
4. Распределение информации по категориям
для всех лиц, заинтересованных в проекте
Периодическое и своевременно предоставление информации о ходе работ на проекте
является одной из основных обязанностей менеджера проекта. Главный вопрос, который
следует задать себе: «Получают ли информацию о проекте именно те люди, которые
должны ее получать, именно тогда, когда они этого хотят, и именно в том формате, в
котором она им нужна?»
Предположим, что мы уже можем приступать к реализации плана информирования,
утвержденного на стадии планирования проекта. Основной акцент следует сделать на
составлении кратких отчетов для руководства и других заинтересованных лиц. Стиль
отчета должен точно передавать статус проекта, при этом не рекомендуется включать
слишком много деталей.
Методы, используемые при составлении отчетов, должны быть объективными и
обладать количественными измерениями, например, «метод критического пути» или
«метод освоенного объема».
Если среди сотрудников проекта есть те, кто работает удаленно от остального
коллектива, то разумно установить некий формат отчетности руководству, который бы
сохранялся до конца проекта и легко читался бы на расстоянии. Примером такого
формата может быть так называемый «светофор». Составляется список основных
планируемых результатов, выделяемых маркерами. Зеленый цвет – работа идет в
соответствии с намеченным планом, желтый – есть небольшое отставание, или
существуют риски, красный – нет продвижения вперед или проект в опасности.
Итак, в отчеты должны включаться такие показатели, как графики работ, стоимость,
объем, качество и риски, т.к. именно по ним судят об успешном развитии проекта.
5. Способы тестирования продукта
Объектами тестирования могут быть:
Планируемый результат. Это может быть некий продукт, документ, здание и
т.д.
Рабочая среда планируемого результата. Если планируемым результатом
проекта является неким компонентом какой-то более крупной системы, то вся
система должна быть подвергнута тестированию. Вопрос только в том, кто
ответственен за тестирование: команда-разработчик компонента, или какая-то
другая команда проекта?
Клиенты. Какую ответственность на себя должны брать сотрудники проекта
относительно того, на сколько хорошо клиенты способны использовать результат
проекта? Следует ли команде-разработчику продукта контролировать конечного
пользователя на умение эксплуатировать продукт? Некоторые продавцы
программ формально тестируют конечных пользователей продукта после
проведения тренинга.
Пользователи сопроводительной документации. Команда может взять на себя
ответственность за проверку комплектности, точности и полезности
документации, предоставляемой пользователю.
Эксплуатационная документация. Умение эксплуатировать, исправлять и
улучшать рабочие качества продукта на основе сопроводительной документации
может быть подвергнуто тестированию.
Техподдержка. Вся инфраструктура должна участвовать в поддержке системы.
Поэтому, тестированию следует подвергнуть все уровни поддержки, начиная с
рядовых исполнителей, заканчивая специализированным персоналом, обязанным
разрешать особо сложные проблемы, связанные с вводом нового продукта.
Воздействие на существующие информационные системы. В области
программного обеспечения влияние на существующие системы может являться
обширной зоной тестирования. Основное внимание следует уделить обеспечению
безопасности воздействия нового продукта на работу уже существующих систем.
Влияние на сопутствующие объекты. Возможно, потребуется протестировать
работу нового продукта относительно сопутствующих его объектов, не
являющихся частью общей системы, включающей новый продукт.
Ассоциированные процедуры. Помимо техподдержки, может появиться
необходимость получить подтверждение того, что процедуры, ассоциированные с
новым продуктом, являются эффективными. Например, если результатом проекта
является создание резервного плана или плана по предупреждению утери
жизненно важной информации то заказчик может потребовать убедить его в том,
что созданная система жизнедеятельна.
Планирование процесса тестирования. После согласования стандартов качества, а
также определения элементов, которые должны быть протестированы, следует начать
разработку более детализированного плана по обеспечению качества надлежащего
уровня. При планировании следует учитывать: предмет тестирования, кем, каким
образом и в каких условиях будет проводиться тестирование, каковы ожидаемые
результаты, кто ответственен за координацию и информирование тестирования, что
будет предприниматься, в случае возникновения проблем и какова общая стратегия
тестирования.
В ходе разработки плана тестирования следует создавать задачи и включать их в ИСР.
Таким образом, разрабатываются графики выполнения работ, штатное расписание, а
также формируется бюджет плана по обеспечению качеством.
Ниже приведены примеры некоторых общепринятых типов тестирования в сфере
информационных технологий.
Тестирование компонентов системы относится к самым нижним типам процедуры
тестирования в проектах IT, и производится самим разработчиком.
Модульное тестирование (юнит-тестирование) — тестируется минимально возможный
для тестирования компонент, например, отдельный класс или функция.
Интеграционное тестирование— проверяет, есть ли какие-либо проблемы в интерфейсах
и взаимодействии между интегрируемыми компонентами — например, не передается
информация, передаётся некорректная информация.
Системное тестирование— тестируется интегрированная система на её соответствие
исходным требованиям
Альфа-тестирование — имитация реальной работы с системой штатными
разработчиками, либо реальная работа с системой потенциальными
пользователями/заказчиком на стороне разработчика. Зачастую альфатестирование применяется для законченного продукта в качестве внутреннего
приёмочного тестирования. Иногда альфа-тестирование выполняется отладчиком,
или с использованием окружения, которое помогает быстро выявлять найденные
ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для
дополнительного исследования в окружении, подобном тому, в котором будет
использоваться ПО.
Бета-тестирование — в некоторых случаях выполняется распространение
версии с ограничениями (по функциональности или времени работы) для
некоторой группы лиц, с тем, чтобы выявить любые остаточные ошибки. Иногда
бета-тестирование выполняется для того, чтобы получить обратную связь о
продукте от его будущих пользователей.
Регрессивное тестирование (regression testing ) — собирательное название для всех видов
тестирования программного обеспечения, направленных на обнаружение ошибок в уже
протестированных участках исходного кода. После внесения изменений в очередную
версию, регрессионные тесты подтверждают, что сделанные изменения не повлияли на
работоспособность остальной функциональности приложения. Регрессионное
тестирование может выполняться как вручную, так и программой, автоматизирующей
этот процесс.
Стрессовое тестирование (stress testing) Очень часто перед администратором встает
необходимость протестировать работу сервера под реальной нагрузкой. В такой
ситуации на помощь могут прийти средства нагрузочного тестирования (stress testing
utility). Такие утилиты специально предназначены для того, чтобы имитировать работу
большой группы пользователей.
Пилотное тестирование (Pilot testing) подразумевает тест в производственной среде и
должно учитывать все характеристики производственной среды для проверки всех задач
развертывания. Этим процессом руководит специализированная группа тестирования,
готовая устранить любые неполадки, выявленные в ходе тестирования.
Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing).
Приемочное тестирование часто называют Системой приемочных испытаний,
производимых пользователем (UAT) или заказчиком (CAT). Формальный процесс
тестирования, который проверяет соответствие системы требованиям и проводится с
целью:
-определения удовлетворяет ли система приемочным критериям;
- вынесения решения заказчиком или другим уполномоченным лицом
принимается приложение или нет.
вынесения решения о проведении приемочного тестирования когда:
- продукт достиг необходимого уровня качества;
- заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или
иным документом, где описан набор действий, связанных с проведением
приемочного тестирования, дата проведения, ответственные и т.д.
Итак, приемочное тестирование должно подтвердить ожидания и потребности заказчика,
которые были определены на стадии инициации проекта.
Результаты тестирования могут быть как полностью неприемлемыми, так и абсолютно
удовлетворительными. Об этом стоит задуматься еще на стадии планирования, а также
быть готовым к тому, что не все результаты будут удовлетворительными. Имеется в
виду, что задачи по корректировке обнаруженных дефектов, а также повторное
тестирование должны быть внесены в ИСР. Надежда на полный успех в стадии
планирования может привести к провалу.
Результаты тестирования в отдельно взятой фазе должны дать ответ на главный вопрос:
«Готов ли проект продвигаться к следующей фазе?»
6. Оценка проделанной работы:
метод освоенного объема
(Earned Value Technique)
Контроль и управление проектом подразумевает умение его руководителем определять,
укладывается ли проект в запланированный бюджет и будет ли он завершен в
запланированные сроки. Для этого недостаточно собирать фактические данные о ходе
работ - нужно еще и правильно их анализировать.
Как известно, одной из главных черт проекта является ограниченность во времени и
ресурсах. Поэтому во время его отслеживания руководителю нужно уметь определять
динамику хода работ. Однако определить динамику невозможно, основываясь на
простых данных о фактических затратах и трудозатратах. При контроле бюджета
проекта, как правило, сравниваются показатели фактического (AC – Actual Cost фактическая стоимость выполненных работ) и планового (PV – Planned Value - сметная
стоимость запланированных к выполнению за рассматриваемый период времени работ)
количества потраченных ресурсов на заданный момент времени, возникает
неоднозначность в объяснении причин отклонений.
Предположим, показатель AC > PV, то есть мы фактически потратили больше средств,
чем было заложено в бюджете. К сожалению, невозможно сделать вывод о причине
увеличения затрат - сделано больше работ или работа обошлась дороже.
Для того чтобы правильно интерпретировать причины отклонений и вводится понятие
освоенного объема (EV – Earned Value - плановая (сметная) стоимость выполненных
работ).
Метод освоенного объёма (Earned Value Analysis) — ряд методов, объединенных под
общим названием, использующихся для измерения и контроля эффективности
выполнения проектов.
Для того, чтобы рассчитать показатель освоенного объема проектных работ на
определенный момент времени, можно воспользоваться одним из следующих методов:
суммировать бюджетные затраты выполненных на данный момент времени работ
(“снизу вверх”);
рассчитать долю выполненного объема работ от текущего прогноза их общего
объема и умножить на PV проекта (“сверху вниз”)
Подход “сверху вниз” очевиден для тех работ, которые были запланированы и уже
завершены, — для них PV равно их бюджетной стоимости. Второй подход используется
для учета работ, которые были запланированы, но еще не завершены, используется , а
именно предполагают, что:
EV = (AC /EAC)* PV, где EAC - текущий прогноз затрат на данную работу; AC/EAC
показывает долю уже понесенных затрат в общем объеме затрат на выполнение работы
(то есть оценку степени готовности результата)
Практика показывает, что второй подход к вычислению освоенного объема проекта в
целом, состоящий в применении формулы к параметрам всего проекты (“сверху вниз”), в
большинстве случаев более эффективен.
Метод освоенного объема отличается 2 характерными особенностями:
Освоенный объем может рассчитываться как в стоимостных, так и в натуральных
показателях. Если используются разнородные ресурсы (материалы, трудовые
ресурсы), то предпочтительно использование стоимостных показателей. Если
ресурсы однородны и имеют примерно одинаковую стоимость (например,
трудозатраты в компании с высокими накладными расходами на человеко-час), то
возможно использование натуральных показателей.
Метод освоенного объема является упрощенным, ориентированным на
использование в проектах, вариантом метода анализа отклонений при учете по
нормативным затратам.
Анализ по методу освоенного объема подразумевает оценку по стоимости и по срокам
следующих величин:
1. Соотношение фактических затрат с плановыми:
2. Опережение/отставание от графика;
3. Тенденции выполнения проектных работ.
Динамика показателей проекта по методу освоенного объема
Исходя из данного графика, можно сделать следующие выводы:


По состоянию на середину марта выполнено работ на сумму примерно на 20 у.е.
меньше, чем было запланировано, но на их выполнение потрачено средств
примерно на 140 у.е. больше (имеет место отставание от графика и перерасход
средств).
На данный момент работы отстают от графика примерно на одну неделю. Только
что оправданы выполненным объемом работ средства, потраченные около 1,5
недель назад.
 Темпы выполнения работ больше плановых, отставание уменьшается. При
сохранении существующих тенденций где-то в течение одной недели работа уже
будет идти по графику и даже с опережением.
 Темпы расходования средств выше темпов выполнения работ, перерасход
увеличивается. При сохранении существующих тенденций проект будет
выполнен с большим перерасходом средств, чем есть сейчас.
7. Результаты этапа выполнения работ
и контроля
Организация, которая стремится к успешному выполнению работ и контролю, должна
придерживаться следующих правил:
следует разработать механизм учета затраченного времени и вложенных
средств на выполнение задач проекта, причем все сотрудники проекта должны
владеть этим механизмом;
план реализации проекта всегда должен отражать текущее положение дел,
включать риски, стоимость и прогнозируемые сроки завершения проекта;
статус проекта и ожидаемые результаты должны периодически оцениваться при
помощи метода освоенного объема;
аудиты управлением проекта должны периодически проводиться внешними
компаниями. Результаты аудитов используются для внесения улучшений, как в
ход реализации проекта, так и в управление всей организации в целом .
обзоры контрольных событий должны проводиться в установленном порядке;
для определения статуса проекта должен быть использован простой и понятный
формат проведения отчетности. Формат должен включать объективные и
количественные показатели относительно дальнейшего развития, ожидаемых
результатов и сопряженных рисков.
проект следует остановить, если отсутствует дальнейшая надобность в его
результатах;
все планы и документация должны постоянно обновляться;
изменения и запросы на изменения следует постоянно координировать в
соответствии с планом управления изменениями; входящим запросам следует
уделять первостепенное внимание;
следует сформировать комиссию по управлению изменениями;
реализованные изменения, а также их влияние на взаимосвязанные с ними
системы, должны быть тщательно протестированы;
моральное состояние команды проекта должно быть под контролем, должна
проводиться постоянная работа по поддержанию и улучшению морального
состояния сотрудников;
общение с продавцами, консультантами, а также третьими сторонами должно
быть открытым и последовательным;
для эффективного управления проектом следует использовать современные
технические средства, обеспечивающие, например, проведение видео
конференций, иные инструменты взаимодействий, онлайн-архив документов и
т.д.
первоначальный утвержденный план проекта не должен изменяться, за
исключением изменений, прошедших согласование.
5. Закрытие проекта
1. Что означает «закрыть проект»?
2. Согласование со всеми
заинтересованными сторонами
3. Сдача результатов проекта
4. Передача накопленных знаний
5. Роспуск команды
6. Результаты этапа закрытия проекта
1. Что означает «закрыть проект»?
Закрытие проекта является самым важным и самым трудным этапом его жизненного
цикла. Мотивация персонала исчерпана, члены команды изъявляют желание перейти к
новым проектам, однако еще многое необходимо завершить, прежде чем можно
объявлять о полном окончании проекта.
Во-первых, необходимо выполнить все формальные процедуры. Иными словами, если
проект выполнялся в согласовании с пунктами контракта, необходимо понять, как
презентовать сторонам контракта результаты выполненных заданий. Проект не может
считаться закрытым без формального принятия заказчиком конечного продукта или
результата проекта.
Во-вторых, необходимо решить все административные вопросы, которые могут
оказаться важнее, чем формальные пункты проекта, особенно в том случае, если проект
был реализован без заключения контракта. В административные задачи руководителя
проекта на этапе его закрытия должны быть включено следующее.

Осуществить все оставшиеся по проекту выплаты поставщикам, контрагентам и
другим заинтересованным сторонам.
 Закрыть все кредиты после погашения всех платежей.
 Получить платежи по проекту, если он выполняется для клиента,
финансирующего выполнение работ.
 Пересмотреть и обновить всю документацию;
 Обновить картотеку данных по персоналу или предоставить функциональным
менеджерам команды информацию для того, чтобы они могли составить отчет по
проделанной работе участников проекта в следующем проекте.
 Составить полную документацию данных по проекту и удалить ненужную
информацию;
Составить список использованных активов баланса проекта, которые можно
применить в других сферах организации;
 Подтвердить выход из проекта определенных заинтересованных сторон с тем,
чтобы завершить проект.
 Оценить степень удовлетворения заинтересованных сторон результатами проекта,
а также работой его руководителя.
 Собрать все полученные знания и опыт в одном месте для их дальнейшего
использования;
 Распустить команду проекта, дав им возможность приступить к работе над
другими задачами организации;
 Освободить рабочее пространство (офис) проекта;
 Уведомить всех заинтересованных сторон об окончании проекта и доступности
ресурсов для осуществления других видов работ;
 Отметить достижения команды проекта и выразить признание отдельным лицам
за их вклад в развитие проекта или задачи, выполненные сверх нормы.
 Убедиться, что весь спектр заданий выполнен;
 Удостовериться у заинтересованных сторон в применимости и высоком качестве
результатов проекта и получить от них письменное подтверждение.

Одним из форс-мажорных обстоятельств во время закрытия проекта может стать
необходимость выполнить задачи, которые не были включены в ИСР. Результатом такой
непредусмотрительности может стать превышение бюджета и графика проекта, что
может нанести урон репутации компании в дальнейшем. Чтобы предотвратить
возникновение подобных ситуаций, необходимо составить список задач, которые нужно
выполнить для того, чтобы закрыть проект.
Кроме того, как уже говорилось ранее, этап завершения проекта подразумевает создание
и систематизацию архива данных – единого файла документов, в котором хранится
вся информация по проекту, доступная всем ее участникам. Как правило, в крупных
компаниях юридический отдел составляет программу хранения данных, в которой
задаются параметры и сроки службы тех или иных документов. Это особенно важно для
финансовой документации проекта, которая должна учитывать все нюансы
законодательной и налоговой систем страны.
При систематизации архива данных необходимо очистить его от ненужной информации.
Это является важным по двум причинам. Во-первых, лишняя информация затрудняет
поиск необходимых документов. Во-вторых, посторонние файлы могут нанести ущерб
организации в случае, если потребуется провести юридические процедуры
(судопроизводство, проверки и т.д) в отношении проекта.
Таким образом, создание архива данных является необходимым по ряду причин.
Соблюдение требований законодательства
 Проведение аудиторской проверки в случае необходимости повторного
рассмотрения проекта;
 Проект как ориентир для реализации других программ и видов деятельности.

Последний пункт является, по сути, самым важным элементом управления проектами,
ключевая мысль которого – использовать достижения предшествующих проектов в
совершенствовании планирования и реализации текущего проекта.
Кроме того, в некоторых проектах есть возможность перераспределения внеоборотных
активов и их повторного использования в качестве компонента фазы закрытия проекта.
Сюда относится программное обеспечение, комплектующие, капитальное оборудование,
площадки для проведения испытаний и т.д. менеджер проекта в данном случае
ответственен за обеспечение перераспределения основных средств, обновления их
статуса в базе данных и возможности их дальнейшего использования в процессе
производства.
2. Соглашение со всеми
заинтересованными сторонами
Проект не может быть завершен, если мы не можем получить согласия от
заинтересованных сторон относительно результатов работы. Нам необходимо не просто
их одобрение, а подтверждение и письменное подтверждение выхода из проекта того
лица (заказчика, спонсора и т.д.), который признает факт достижения поставленных
целей.
Подписание финального соглашения с заказчиками проходит значительно легче, если
менеджер проекта заблаговременно согласовывает с ними результаты промежуточных
отчетов или этапов и добивается их одобрения. В этом случае, формальное утверждение
выхода из проекта его заказчиков означает их согласие с результатами последнего этапа,
а не всего проекта в целом.
Успех соглашения с нашими клиентами зависит также от того, насколько составленные
нами программы планирования (например, состав и объем работ) обеспечивают
достижение целей проекта.
3. Сдача результатов проекта
В процессе завершения проекта важным также является передача всех результатов
проекта от группы разработчиков операционному и вспомогательному персоналу
компании. Однако если одни проектные команды сразу же распадаются после сдачи
результатов проекта, другие, напротив, следят за тем, чтобы механизмы поддержки
функционировали должным образом, вплоть до самого окончания проекта.
Для большинства компаний-представителей малого бизнеса группа разработчиков – это
те, кто являются одновременно создателями проекта и лицами, ответственными за его
реализацию. Несмотря на то, что обеспечение требуемых результатов порой отвлекает
персонал от выполнения других заданий, это не так уж плохо, поскольку сдача проекта
не произойдет до тех пор, пока ее непосредственно не инициируют обе стороны.
Поскольку главной задачей управления проектами является выполнение требований
заинтересованных сторон, на этапе сдачи результатов проекта важно убедить их в том,
что их ожидания были оправданы. Это можно осуществить следующим образом.
Подписать акт сдачи-приемки между исполнителем и заказчиком;
 Изучить результаты исполнения задач ИСР;
Пересмотреть соответствующие документы, такие как Содержание работы и сам
контракт;
 Опросить клиентов с целью выяснения факта удовлетворения или
неудовлетворения их требований.


4. Передача накопленных знаний
Как известно, персонал организации считается самым важным активом, а именно
совокупностью знаний, которыми владеют сотрудники. Данная совокупность знаний
охватывает все, что необходимо знать организации, для того, чтобы эффективно
заниматься бизнесом или предоставлять услуги. Итак, мы знаем, каким образом
проводить сбор информации у работников торгового отдела, кем являются наши
заказчики и каковы их цели. Мы владеем структурами наших баз данных, и знаем, каким
образом взаимодействуют наши системы. Нам знакомы организации – поставщики, а
также мы в курсе нормативно-правовой базы, регулирующей область индустрии, в
которой мы работаем. В некоммерческих и государственных секторах мы ориентируемся
в политических процессах, посредством которых происходит финансирование, а также
оказывается влияние на сообщество, в котором мы трудимся.
Передовые организации делают все возможное для обогащения совокупности знаний,
даже, если происходит смена сотрудников. Большой вклад в совокупность знаний
организации вносят хорошо задокументированные завершенные проекты.
Формирование базы данных по проектам позволяет последующим менеджерам проектов
использовать накопленную информацию для развития своей деятельности с большей
эффективностью, лучшим качеством и наименьшим риском.
Менеджер проекта обязан активно вносить вклад в совокупность знаний организации
посредством передачи знаний и опыта, полученных в результате реализации проекта.
Очень важно хранить проектную информацию таким образом, чтобы сотрудники
организации имели к ней доступ, и легко могли бы ею воспользоваться. Однако, вовсе
необязательно для этого хранить всю информацию в архиве проекта. Проведение встреч
с менеджерами других проектов, общих информационных собраний, а также собраний
сотрудников проекта эффективно способствует быстрому распространению
приобретенных знаний. Несомненно, для развития совокупности знаний организации
необходимо фиксировать все полученные данные письменно, желательно в электронной
форме.
Пути к совершенству. Каким конкретно образом накопленные знания хранятся, зависит
от проектов и организаций. Как правило, для этого организуется специальное собрание,
на котором стейкхолдеры обсуждают, что в ходе проекта было сделано правильно, а что
могло бы быть исполнено лучше. На подобные собрания часто приглашаются третьи
стороны. В ходе дискуссии легче выявить полезный опыт и, таким образом, обогатить
совокупность знаний организации. Несомненно, результаты таких встреч должны быть
документально зафиксированы.
5. Роспуск команды
Данная задача подразумевает следующие шаги:
выразить благодарность за вклад, внесенный сотрудниками в достижение
результатов проекта;
оказать содействие сотрудникам в нахождении дальнейшей работы.
Выразить благодарность можно просто, сказав «спасибо», подарив футболки,
фарфоровые тарелки с благодарственной надписью, какие-либо другие памятные
подарки, или же вручив сотрудникам денежное вознаграждение. Здесь важно не
упустить никого из тех, кто внес вклад в проект в той или иной степени. Для чего это
следует делать? Вполне возможно, что будет открыт следующий проект, и вы захотите,
чтобы члены команды продолжили работу именно с вами. Что касается второго шага, то
менеджер проекта, оказывая содействие сотрудникам проекта в нахождении
дальнейшего места работы, может, как просто проинформировать их об имеющихся
возможностях, так и приложить более существенные усилия.
6. Результаты этапа закрытия проекта
Организация, которая стремится к успешному процессу закрытию работ, должна
придерживаться следующих правил:
Следует составить список завершающих мероприятий. Важно не упустить
ничего из того, что может помешать успешному завершению проекта;
Трудовой вклад каждого члена команды оценен и зафиксирован документально;
Все документы должны быть обновлены, и отражать заключительный статус
проекта и его результатов;
Документы проекта должны находиться в компьютерной системе, куда, при
необходимости, могут обратиться другие менеджеры проектов компании;
Должно быть письменное подтверждение того, что цели проекта достигнуты,
конечные пользователи также должны подтвердить этот факт;
Команда проекта должна торжественно отметить закрытие проекта.
Сотрудникам проекта следует вынести благодарность за вклад, внесенный в
достижение результатов проекта;
Накопленные знания должны быть обработаны и доступны всей организации.
Это позволяет использовать накопленный на проекте опыт в дальнейшем, при
возникновении необходимости создавать и планировать аналогичные проекты и
инициативы.
Следует провести оценку удовлетворенности заинтересованных сторон, в
особенности заказчика. Как правило, такая оценка проводится третьей
стороной.
Команда должна подтвердить, что требуемое содержание проекта,
определенное на этапе планирования, было в действительности выполнено.