Презентация на тему Жизненный цикл проекта. Управление проектом. (Лекция 4)

и «содержание работ» проекта. Эти ограничения обычно называют тройственными

и изображают в форме треугольника.

Задача управления проектом сводится к тому, чтобы проект «не выскочил» за грани (сами грани согласовываются до начала работ).

некоторые требования к управлению проектом понятны сразу же:
Управление временем

(необходимо уложиться в срок)
Управление стоимостью (мы не должны превысить бюджет)
Управление содержанием (нам нужно уточнить желания заказчика и правильно их реализовать)
Другие – менее очевидны:
Управление качеством
Управление рисками
Управление закупками (если мы используем субподрядчиков)
Управление персоналом
Управление коммуникациями
Управление интеграцией

с реализацией функций управления и приносящих результат.

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

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

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

времени между появлением обоснованной концепции проекта и моментом административного

завершения проекта.
Инициация (формулирование проекта)
Планирование
Осуществление (реализация, выполнение)
Завершение (закрытие)

жизненного цикла проекта

продукцию;
сроки реализации и сложность проекта;
правовое обеспечение проекта;
конкурентоспособность продукции проекта;
инвестиционный

климат;
оценка экономической эффективности.

(или инвесторов) в необходимости выполнения проекта.
Цели продукта – это

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

в проекте
сбор исходных данных
определение целей и задач проекта
рассмотрение альтернатив
2.

Утверждение концепции проекта
3. Открытие проекта
принятие решения о начале проекта
определение и назначение управляющего проектом
принятие решения об обеспечении ресурсами

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

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

Устав создается менеджером проекта и утверждается спонсором

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

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

всех участников проекта и ориентацию их на достижение конечной

цели.
Виды планов:
концептуальный;
стратегический;
текущий;
оперативный.

проекта
Определение взаимосвязей работ
Оценка длительностей или объемов работ
Определение

ресурсов проекта и их характеристик
Назначение ресурсов
Оценка стоимостей
Составление расписания выполнения работ
Оценка бюджета
Планирование качества
Определение критериев успеха

и назначение ролей, ответственности и взаимоотношений отчетности в организации;

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

нужны планы:
Чтобы не забыть что-то существенное во время выполнения

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

проектных планов. Это общее название ВСЕХ планов проекта, каждый

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

финализировать требования
Сформировать концепцию (scope)
Принять решение «что закупаем»?
Определить команду
Создать ИСР

(иерархическую структуру работ) (WBS - Work Breakdown Structure)
Создать перечень действий (activity list)
Создать сетевую диаграмму (network diagram)
Оценить требуемые ресурсы
Оценить продолжительность действий и стоимость
Сформировать расписание
Создать бюджет
Планировать качество – создать метрики
Создать план улучшения процессов
Распределить роли и ответственности
Создать план коммуникаций
Спланировать управление рисками, идентифицировать риски, качественный анализ, количественный анализ, планировать реагирование на риски
Все повторить

свою работу по заключению договоров и контрактов. Как правило,

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

лиц
Матрица требований
Концепция проекта

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

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

должен содержать десятки (или более) фамилий:
Во-первых, это каждый, кто

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

– вносится название проекта и фамилия и имя менеджера

проекта)

требования: «система должна позволять проходить все пользовательские сценарии без

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

кто автор (кто высказал), насколько данное требование важно (приоритетно).

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

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

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

по проекту необходимо решить ряд вопросов. Есть ли в

нашей компании доступные сотрудники с нужной квалификацией? Требуется ли специфичное оборудование? Может, для выполнения каких-то работ нужна особая лицензия?
Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта.
Необходимо решить, будут ли привлекаться субподрядчики.
Некоторые из «лучших проектных практик» рекомендуют такой подход:
Обязательно использовать субподряды:
Если это снижает риски проекта
Можно использовать субподряды:
Если мы бережем (читай «испытываем дефицит») собственных ресурсов
Если мы пытаемся повысить управляемость проекта
Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.
Результатом определения ресурсов является список ресурсов
Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа или набора электронных писем из корпоративной переписи).

всеми его участниками.
Вспомогательные процессы:
учет исполнения – подготовка и

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

стоимости;
анализ качества;
подтверждение целей.
Вспомогательные процессы анализа :

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

определение, согласование, утверждение и принятие к исполнению корректирующих воздействий

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