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

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

Герасимова Марина Витальевна –
доцент, канд. экон. наук

2. Project Management

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

3. Project Management

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

4. Трактовка термина «проект» ассоциациями управления проектами

5. Признаки проекта

6. Особенности проектной деятельности

7. Подходы к управлению проектом

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

8. Методы управления проектом

Классическое управление по PMI
Гибкие методологии Agile: Scrum и
Kanban, Lean
PRINCE2, Six Sigma, XP, CCPM, ECM,
Waterfall и другие.

9. Классическое управление по PMI

Задачи
удовлетворить потребности
заказчика;
реализовать проект в срок в рамках
установленного бюджета и с
требуемым содержанием.
Процесс
Менеджер проекта:
до старта договаривается с
заказчиком об основных целях и
ограничениях, фиксирует их в
уставе,
управляет рисками,
собирает требования от основных
заинтересованных лиц,
анализирует, оценивает
реализацию задач и затем
распределяет их на этапы,
формирует гибкие планы и уточняет
их на протяжении всего проекта.
Преимущества
Фиксация требований на старте и
стабильность содержания проекта.
Предсказуемость процесса разработки.
Качественная проработка требований экономия времени и силы на исправления
недочетов.
Можно использовать, когда:
заинтересованные лица имеют четкое
видение результата — конечный продукт;
составлено подробное техническое задание
на разработку;
есть жесткие ограничения по сроку и
бюджету проекта;
реализация проекта предполагается по
формату договора fixed price.
Это могут быть проекты:
доработки существующей системы по
готовому техническому заданию;
проекты с четко установленными
требованиями.

10. Гибкие методологии Agile

Идеи Agile:
Преимущества
Быстрый жизненный цикл
разработки.
Гибкость в принятии решений.
Регулярное получение обратной
связи от заинтересованных сторон
открывает возможность вносить
корректировки в реализацию
проекта или в функциональность
разрабатываемого продукта.
Гибкие методологии работают, когда:
детали проекта, требования и
реализация особенностей всех
запланированных модулей /подсистем
еще не до конца определены на
старте.
нет четкого понимания конечного
результата, но есть общее
представление о продукте;
проект нужно быстро корректировать
и подстраивать под изменяющиеся
требования.
Наиболее популярные способы к
управлению в философии Agile:
Scrum и Kanban.

11. Scrum

Основа работы — спринты* длительностью
от 1 до 4 недель, в рамках которых команда
обязуется взять приоритизированный набор
задач из бэклога* и создать инкремент
(работоспособную часть ИТ-продукта,
которая будет нести определенную
ценность).
По завершению спринта команда презентует
результаты основным стейкхолдерам и
владельцу продукта.
Scrum можно использовать для:
управления крупными проектами и
опытной командой, которая умеет
расставлять приоритеты и имеет четкое
представление о требованиях проекта;
проектов по разработке сложных
программных продуктов в условиях
частого изменения требований;
проектов по созданию ИТ-продукта,
нацеленного на пользователя.
Преимущества
Удовлетворенность конечного
пользователя.
Если у кого-то из членов команды
возникнет проблема и он об этом сообщит
на еженедельной планерке или
ретроспективе, команда приложит все
усилия, чтобы помочь ему и реализовать
спринт в срок.
Scrum предоставляет возможность
быстрого тестирования гипотез.
Подводные камни
Не признает ограничений: формируется
видение продукта, и все идут к его
реализации.
Каждый участник должен быть «командным
игроком
Не предоставляет возможности на старте
проекта определить стоимость, сроки и
содержание. Но в процессе реализации
собираются определенные метрики,
позволяющие ретроспективно измерить
производительность, мощность и
количество работы за спринт.
*Бэклог — это список требований к продукту
*Спринт — итерация с фиксированным сроком

12. Scrum

13. Kanban

В команде канбан отсутствуют роли
владельца продукта и модератора, а
процесс разработки делится не на
универсальные спринты, а на стадии
выполнения задач
Преимущества
Его можно адаптировать под конкретные
процессы. Между to-do и done могут быть
разные колонки.
Быстрая поставка ценности. В Scrum
команда «заливает» фичи на production
только в конце спринта, в Kanban — после
приемки тестировщиком. Это позволяет
быстрее узнать, «зашла» фича
пользователям или нет.
Этот метод ограничивает количество задач,
над которыми команда может работать в
один момент времени.
Виден прогресс и минимизируются застои.
Доска Канбан в сфере программного
обеспечения включает колонки:
Execute – задачи, которые требуется
проработать.
Work – карточки в работе.
Specify – уточнить информацию.
Does – задачи выполненные, но не прошедшие
тестирование.
Test – задачи на тестировании.
Management – задачи на согласовании
руководителем проекта.
Finish (Ok) – выполненные задачи.
Наименование колонок не фиксированное и
зависит от специфики проекта – могут
добавляться или отсутствовать из
вышеперечисленных.

14. lean-принципы управления

Lean ― это философия бережливого мышления. Подход, который позволяет экономить
ресурсы и получать лучший результат.
Цель Lean ― создавать ценность, сокращая расходы на ее производство.
Это не методология, поэтому в ней нет набора готовых практик. Конкретных правил тоже нет, но
есть приемы, которые помогают извлекать пользу.
Lean ― это часть философии Agile. Если говорить о разработке ПО, то бережливое мышление ―
основа для любой гибкой методологии
Lean-разработчики ориентируются на ценности бережливого мышления:
-Ликвидировать потери. Если действие не улучшает качество продукта, не приносит прибыли заказчику и не
экономит время разработчика, то его нужно исключить.
- Усиливать обучение. Команда должна постоянно совершенствовать свои знания и навыки. А руководитель ―
обеспечивать команду временем и ресурсами.
- Принимать важные решения в последний момент. Иногда запоздало принятое решение может испортить всю
проделанную работу, но для Lean откладывать принятие решения до последнего ― это способ собрать как можно
больше информации о вопросе. А значит, быть уверенным в его правильности и избежать ошибок.
- Доставлять ценность как можно раньше. Чем раньше команда покажет свои наработки заказчику, тем быстрее
получит от него обратную связь. Разработчики будут уверены, что все делают так, как хочет клиент.
- Объединять сотрудников. Когда команда работает сообща и понимает свою ценность, процесс идет быстрее и
эффективнее. Поэтому важно доверять сотрудникам и ценить то, что они делают.
- Создавать целостный продукт. Команда должна сфокусироваться на качестве, не допускать дефектов и всегда
ставить в приоритет потребности заказчика.
- Следить за общим процессом. Чтобы работа шла хорошо, каждый в команде должен понимать задачи и иметь
возможность постоянно видеть весь процесс. Вся информация по проекту должна быть доступна в любое время.
Для этих целей в гибких методологиях (Scrum, Kanban) используют доску, где отмечены цели, задачи и процесс их
выполнения.

15. lean-мышление

Для lean-мышления потери недопустимы, поэтому их нужно исключить.
Виды потерь при разработке ПО
Недоделанная работа. Это может быть написанный, но неиспользованный
код. Лишний код — зря потраченное время.
Ненужная функциональность. Возможности, которые добавили в ПО, но которые
не используются потребителем, не приносят пользы. Клиенту нужны только
полезные функции.
Повторное изучение. Если разработчик приступил к одному проекту, а потом его
перекинули на другой, придется заново вникать и собирать информацию.
То же самое происходит, если в команде проекта появляется новый разработчик.
Весь процесс начнется сначала.
Передача. Проект или его части передают из одних рук в другие. Так происходит
передача не только проекта, но и ответственности за него. В результате команды
теряют контроль над ситуацией.
Переключение между задачами. Когда один разработчик выполняет два проекта
одновременно и постоянно должен переключаться с одних задач на другие,
он теряет больше времени, чем мог бы, работая над одним проектом.
Ожидание. Если команда постоянно занимается согласованием документов
с заказчиком, то тратит много времени и в результате срывает сроки проекта.
Дефекты. Команда должна следить за качеством кода еще на начальных этапах.
Если по окончании работы будут найдены критические ошибки, то придется
начинать проект сначала.

16. Методология XP («Extreme Programming»)

Одна из гибких методологий
разработки программного обеспечения
Основные практики
Парное программирование
Два разработчика садятся за один компьютер и пишут код. Вместе работают над одной функцией
продукта. Сначала решение предлагает один, второй наблюдает и по ходу комментирует
и исправляет ошибки.
Потом программисты меняются местами и процесс повторяется.
Из двух решений выбирают лучшее и чистят код до идеального состояния.
Разработка через тестирование
Подготовка к тестированию начинается еще до начала написания кода. Сначала пишет тесты, а
потом — код.
Свободный доступ к коду
Любой разработчик может править код, который написал его коллега по команде.
Единое оформление кода
Чтобы код выглядел одинаково, команда использует единый стиль.
Непрерывная интеграция
Новые части кода постоянно встраивают в уже имеющийся. Так разработчикам проще выявлять
ошибки.
Общее видение системы
Чтобы программисты одинаково понимали результат, который должны получить, используется
метафора. Систему сравнивают с чем-то, что понятно и знакомо всем в команде.
Никаких переработок
Норма работы — не более40 часов в неделю.
Как работает команда
Все начинается с выяснения требований и планирования. Задачи записывают на карточки,
выясняют у заказчика последовательность, в которой он хочет получать функционал продукта.

17. Метод PRINCE2

PRINCE2 это акроним от Projects IN Controlled Environments 2, то есть
«Проекты в контролируемых средах».
Методологию можно было смело назвать PRINCE7, так как в ней всего по семь:
принципов, основных процессов и бизнес-инструментов (тем).
PRINCE2 – это методология управления проектами любого типа, основанная на
процессах. Она позволяет наиболее точно и правильно ответить на следующие
ключевые вопросы:
Что мы планируем сделать/создать (цель)?
Когда мы начнём это делать (сроки)?
Что нам для этого нужно (обеспечение)?
Нужна ли нам для этого помощь (сотрудники/команда)?
Сколько это займёт времени (длительность/дедлайн)?
Сколько это будет стоить (бюджет)?

18. 7 Принципов PRINCE2

1.
2.
3.
4.
5.
6.
7.
Непрерывное бизнес-обоснование. Оформляется отдельным документом, который
обновляется на каждом новом этапе проекта, чтобы обеспечить его жизнеспособность.
Обучение на собственном опыте. Внутри каждого (любого) проекта по PRINCE2 от одной и той
же команды обязательно должно вестись документирование опыта (уроков), тогда новые проекты
смогут постоянно обращаться к своим внутренним журналам уроков или к журналам уроков
параллельных/предыдущих проектов, чтобы не изобретать «велосипеды» заново. Если уроки не
провоцируют изменения, они являются только выявленными (неусвоенными) уроками.
Определение ролей и обязанностей. Роли в PRINCE2 обязательно должны быть определены.
Роли обычно разделены на четыре уровня (по восходящей: уровень команды, уровень
руководителя проекта, совет проекта, уровень управления компанией). Группа управления
проектом должна включать представителей всех заинтересованных сторон, в соответствии с
PRINCE2 это бизнес-спонсоры, поставщики ресурсов и конечные пользователи.
Управление по этапам (стадиям). Каждый этап строго описан ниже, при переходе с одной
стадии жизненного цикла проекта к другой нужно обязательно актуализировать документы по
рискам, общий план проекта и бизнес-обоснования.
Управление по исключениям. Если для реализации отдельных целей в проекте PRINCE2
нарушаются определённые изначально допуски (лимиты), то управление передается на уровень
выше, чтобы ускорить процесс принятия решения.
Фокусирование на продуктах. Нужно создавать продукты, которые интересны конечным
пользователям, поэтому эти продукты и их характеристики должны быть детально описаны и
определены.
Адаптация к среде проекта. Методология PRINCE2 говорит о том, что следует учитывать
следующие аспекты – размер проекта и его сложность, временные рамки, важность проекта и
возможные/потенциальные риски. Адаптация должна быть непрерывной, она проверяется
(актуализируется) на каждом этапе – перед его началом и даже в процессе.
Принципы нельзя переделывать или изменять, иначе методология управления уже не

19. 7 основных процессов PRINCE2

1.
2.
3.
4.
5.
6.
7.
Запуск проекта. Назначаются/выбираются участники команды, руководитель и
менеджер, формулируются цели и задачи проекта.
Инициализация проекта. Уточняется экономическое обоснование и собирается
документация по запуску.
Руководство проектом. Выбираются методы и инструменты, с помощью которых
Совет проекта будет контролировать проект.
Управление стадиями. Определяется, как следует контролировать каждый
отдельный (новый) этап, включая контроль отдельных задач и их пакетов.
Управление поставкой продукта. На этой стадии нужно формализовать то, как
задачи по проекту будет передаваться от менеджера проекта к менеджерам групп (к
командам), чтобы такие задачи были согласованы с общим прогрессом и строго
соответствовали требованиям к качеству.
Управление границами стадии. Определяется, как переходить от одного этапа
реализации проекта к другому (очередному/следующему).
Закрытие проекта. Включает процедуру передачи проекта заказчикам, обеспечение
поддержки/сопровождения, а также анализ результатов (выгоды, рекомендации,
инциденты, риски и т.п.).
Как выглядит связка PRINCE2 + Agile
PRINCE2 может использоваться как высокоуровневый фреймворк, который будет применяться к
основным жизненным циклам проекта: инициализация, планирование, завершение и т.п. По
гибкой методологии будет работать только стадия основного производства (реализации).
Поэтому PRINCE2 можно адаптировать для работы с любой гибкой методологией: SCRUM,
канбан и т.д.

20. Метод P2M

Стандарт P2M (Project & Program Management for Enterprise Innovation) был создан
в Японии в 2001 году как национальный стандарт по управлению проектами,
отличающейся от привычных западных подходов, в том числе ориентацией на
создание дополнительных ценностей для компании и прямой корреляцией
производимых изменений бизнеса с миссией предприятия.
Основа методологии стандарта – трилемма Complexity, Value and Resistance:
сложность, ценность и сопротивление. Проекты в работе должны: Быть сложными
и стратегически связанными друг с другом; Приносить компании ценность;
Реализоваться вопреки сопротивлению внешней среды.
Стандарт P2M призван помочь компаниям работать в условиях нестабильной и
неблагоприятной окружающей среды.

21. Метод Waterfall и его принципы

Методология Waterfall — её ещё называют каскадной или водопадной — это
классическая модель жизненного цикла разработки ПО. Была придумана в 1950-х
годах, и, пока не появился Agile, все продукты и проекты реализовывали с её
помощью.
Методология строится на 8 главных принципах. Вот они:
Документирование важно. Все этапы работы должны быть зафиксированы
Каждый этап последователен: следующий этап начинается после окончания
предыдущего
Пропуск этапов плана запрещен
Если в процессе разработки требования к функционалу поменялись, вносим
изменения в ТЗ
Откат на прошлый этап невозможен, ничего менять нельзя
Разработка происходит в рамках одного процесса. Итераций нет
Работа над ошибками — после окончания разработки
Участие клиента ограничивается этапом разработки ТЗ. Привлекать клиента к
работе над продуктом нельзя
Waterfall много критикуют. За недостаточную гибкость, за громоздкость, за
обязательную формализацию управления проектом в ущерб срокам, бюджету и даже
качеству. Но для больших проектов как раз в формализации и есть большая ценность

22. Основные принципы P2M

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

23. Управление проектом

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

24. Основные параметры проекта

Объем
работ
Бюджет
Х – идеальная точка (качество проекта)
Время

25. Ограничения и допущения проекта

Ограничения проекта (project
constraints) - барьеры,
накладываемые на проект.
Примеры ограничений:
• Ресурсные ограничения:
нефти в месторождении
хватит на 15 лет;
• Календарные: строительство
должно быть завершено к
январю 202Хг.
• Технические ограничения:
заливка фундамента,
строительство каркаса.
Допущения (assumptions) –
некоторые утверждения или
факторы, принятые для целей
планирования данного проекта как
правильные, истинные, реальные
или определенные.
Пример допущений:
• возможное освобождение (или,
наоборот, прием на работу)
ключевого менеджера через
некоторое время после начала
проекта;
• утверждение, что финансирование
и другие ресурсы будут доступны
по мере необходимости по
требованию и др.

26. Иерархия «проект — программа — портфель — стратегия»

27. Иерархия «проект — программа — портфель — стратегия»

СТРАТЕГИЯ – это общая концепция того, как достигаются главные
цели организации, решаются стоящие перед ней проблемы и
распределяются необходимые для этого ограниченные ресурсы,
дополненная программой реальных действий, направленных на
приобретение конкурентных преимуществ.
ПРОГРАММА - совокупность
взаимосвязанных проектов и
другой деятельности,
направленных на достижение
общей цели и реализуемых в
условиях общих ограничений.
(ГОСТ Р 54871-2011/2019)
ПОРТФЕЛЬ - набор компонентов,
которые группируются вместе с
целью эффективного управления
и для достижения стратегических
целей организации.
(ГОСТ Р 54870-2011/2019)

28. Особенность IT проектов

Под ИТ-проектом подразумевается процесс, направленный на
создание уникального продукта или услуги, связанный с модернизацией
или интеграцией информационных систем в бизнес-процессы организации.
Особенности
нестандартный жизненный цикл, который может включать в себя
также тестовый, гарантийный и постгарантийный этапы
разработки;
необходимость четкого определения, уже на этапе инициации,
требований к IT-проектам;
необходимость оперативного внесения изменений на этапе
тестирования, что создаёт сложности, с которыми сталкиваются
практически все руководители IT-проектов, вследствие чего
происходит отставание от запланированных сроков;
велико влияние человеческого фактора: сроки и качество
выполнения проекта в основном зависят от непосредственных
исполнителей и коммуникации между ними;
большие финансовые расходы и высокий уровень риска.

29. Классификационные признаки IT проектов

по классу
по масштабу
по типу
Классификация
проектов
по длительности
по виду
по сложности

30. Классификация IT проектов

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

31. Классификация IT проектов

По масштабу проекта - по
размерам самого проекта:
малыми (около 10 тыс. руб.),
средними (10–50 тыс. руб.)
большими (50–100 тыс. руб.)
значительными (100–1000 тыс.
руб.)
сверхзначительными (более 1
млн. руб.)
По длительности проекта - по
продолжительности периода
осуществления проекта:
краткосрочные (до 1 года);
среднесрочные (от 1 до 3 лет);
долгосрочные (свыше 3 лет).
По виду полученных конечных
результатов:
o системы,
o программы,
o технические средства,
o программно-технические комплексы,
o работы и услуги.

32.

Проект не существует сам по себе, а находится в
динамичной внешней среде

33. Окружение проекта

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

34. Окружение проекта

Факторы внешнего окружения:
политические условия;
экономические факторы;
правовые условия;
социальные условия;
инфраструктура;
природные и климатические условия.

35. Окружение проекта

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

36. Основные участники проектной деятельности

Заказчики
Инициаторы
Инвесторы
Участники ITпроектов
Команда проекта
Руководитель
Куратор проекта

37. Основные участники проектной деятельности

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

38. Элементы системы управления проектами

субъекты управления проектами
(внешние и внутренние участники
проекта);
объект управления, в качестве которого
рассматривается сам проект;
процессы управления
(процессы инициации, планирования,
исполнения, контроля и завершения).

39. Жизненный цикл проекта

• Промежуток времени между моментом формализации идеи или утверждения
технического задания проекта и моментом его закрытия, т. е. от состояния,
«когда проекта еще нет», до состояния, «когда проекта уже нет» называется
жизненным циклом проекта (ЖЦП).

40. Жизненный цикл проекта

ИНИЦИАЦИЯ
• Определение
потребностей
заказчика, рыночной
возможности,
проблемы как идеи
для проекта.
• Разработка идеи
проекта с оценкой
первых рисков и
ограничений.
• Формализация идеи в
виде письменного
документа.
• Подготовка Устава
проекта, подписание
договора.
КОНЦЕПЦИЯ
• Концептуальная
разработка
утвержденной идеи, ее
экспертиза.
• Принятие решения о
продолжении разработки
проекта, проведение
конкурса или тендера,
внутреннее решение о
финансировании
проекта.
ПЛАНИРОВАНИЕ
• Разработка и
утверждение базового
плана проекта.
• Формирование и
развитие команды
проекта

41. Жизненный цикл проекта

РЕАЛИЗАЦИЯ
ЗАВЕРШЕНИЕ
• Организация выполнения
планов работ.
• Проведение завершающего
совещания с заказчиком.
• Детальное проектирование и
разработка технических
спецификаций.
• Закрытие бюджета проекта и
контракта.
• Организация и управление
материально-техническим
обеспечением и комплектацией.
• Выполнение операций,
предусмотренных проектом.
• Оперативный контроль и
регулирование хода работ.
• Подготовка официальной
отчетности по проекту.
• Увольнение команды и
руководителя проекта.
• Эксплуатационные испытания
продуктов проекта.
• Закрытие проекта.

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

Генеральный директор
Заместитель генерального
директора по маркетингу
Заместитель генерального
директора по производству
Координация проекта
Заместитель генерального
директора по МТС
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Серым цветом выделен персонал, задействованный в работах проекта
Рисунок - Функциональная организация проекта

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

Генеральный директор
Заместитель генерального
директора по маркетингу
Заместитель генерального
директора по
производству
Заместитель генерального
директора по МТС
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Менеджер проекта
Серым цветом выделен персонал, задействованный в работах проекта
Координация проекта
Рисунок - Сбалансированная матричная организационная структура

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

Генеральный директор
Заместитель
генерального
директора по МТС
Руководитель
менеджеров проекта
Заместитель
генерального
директора по
маркетингу
Заместитель
генерального
директора по
производству
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Менеджер проекта
Серым цветом выделен персонал, задействованный в работах проекта
Координация проекта
Рисунок - Сильная матричная организационная структура

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

Генеральный директор
Менеджер проекта
Менеджер проекта
Менеджер проекта
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Серым цветом выделен персонал, задействованный в работах проекта
Рисунок - Проектная организационная структура

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

Генеральный директор
Заместитель
генерального
директора по МТС
Руководитель
менеджеров
проекта
Заместитель
генерального
директора по
маркетингу
Заместитель
генерального
директора по
производству
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Персонал
Менеджер проекта
Серым цветом выделен персонал, задействованный в работах проекта
Координация проекта В
Координация проекта А
Рисунок - Комбинированная организационная структура

47. Варианты организации управления проектами

Если механизмы управления и источники основных ресурсов проекта находятся в рамках
одной организации, то создается внутрифирменная организационная структура УП
Выделенная структура управления

48.

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

49.

• Если деятельность материнской
организации полностью состоит из
деятельности по УП, то возникает структура
всеобщего управления проектами.

50. Двойственная организационная структура управления

51. Управление — функция заказчика

Организационная
структура заказчика
Организационная
структура проекта
Организационные структуры
подрядных организаций

52. Схема управления - функция управляющей фирмы

Организационная структура
заказчика
Организационная структура
генподр компании
Организационная структура
проекта
Организационная структура подрядной организации

53. Стандарты управления проектами

Международные стандарты
• получившие международное значение в процессе своего развития или
предназначенные для международного использования (ISO 21500:2015
и др.)
Национальные стандарты
• созданные для применения внутри одной страны или получившие
общенациональный статус в процессе своего развития (PMBoKGuide,
ГОСТ Р 54869-2011 и др. )
Общественные стандарты
• подготовленные и приняты сообществом специалистов
Частные стандарты
• комплексы знаний, пропагандируемые для свободного использования
частными лицами, компаниями или учреждениями
Корпоративные стандарты
• разработанные для применения внутри одной компании или внутри
группы родственных компаний.

54. Международные стандарты

IPMA Competence Baseline (ICB) является международным нормативным
документом, определяющим систему международных требований к
компетентности менеджеров проектов. Этот стандарт разработан
международной ассоциацией IРМА (International Project Managers Association).
Стандарт ISO 21500 - Руководство для управления проектами. Разработан
Международной организацией по стандартизации (ISO).
Стандарты практической компетентности проектных менеджеров категорий GL1
и GL2, разработанные Международным объединением по разработке
Стандартов управления проектами (GAPPS)
Project Management Body of Knowledge (PMВОК) Американского института
управления проектами (Project Management Institute – PMI). Этот стандарт де
факто-международный, обновляется приблизительно один раз в четыре года.
Один из наиболее проработанных стандартов, лежит в основе многих
международных и национальных стандартов. Последняя версия PMВОК 7,
2021г. содержит Agile подход.

55. Российские стандарты УП

Российская
Ассоциация
Управления
проектами
«СОВНЕТ»
ГОСТ Р 53892-2010
Руководство по оценке
компетентности
менеджеров проектов;
Особенности национальных стандартов:
ГОСТ Р 54869-2011
«Проектный менеджмент.
Требования к
управлению проектом»;
ГОСТ Р 54870 -2011
«Проектный менеджмент.
Требования к
управлению портфелем
проектов»;
ГОСТ Р 54871-2011
«Проектный менеджмент.
Требования к
управлению
программой»
проектный
подход,
который
подразумевает
в
обязательном
порядке
выделение
отдельной
организационной структуры для управления проектом;
содержат только то, что обязательно должно
присутствовать в проектной деятельности предприятия;
универсальность, подразумевающая, что требования
стандарта распространяются на управление любыми
проектами и могут быть применены для проектов,
реализуемых как физическими, так и юридическими
лицами, а также подрядчиками или исполнителями
внутри организации.
ориентированность на результаты, т.е. стандарт
определяет только обязательные выходы процессов УП,
но не содержит требований к методам реализации этих
процессов.
Особое внимание
документации.
в
стандартах
уделено
проектной

56. Процессы управления проектом

57. Оценка проектной идеи

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

58. Оценка эффективности проекта

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

59. Оценка эффективности проекта

60. Менеджер проекта

Менеджер проекта — это лицо, ответственное за достижение целей проекта,
ответственное за управление проектом, своевременное выявление
конфликтов и их решение.

61. Группы процессов управления проектом

62. Основные документа проекта

63. Содержание Устава проекта

Входные данные
процесса разработки
устава проекта
Техническое
задание на
проектные работы
Договор
Экономическое
обоснование или
документация
предшествующих
фаз жизненного
цикла проекта
(ГОСТ Р ИСО
21500-2014)
Устав проекта отражает в
краткой форме все
составляющие проекта и
является документом,
который формально
авторизирует проект

64. Пример Устава

Структура Устава проекта Международной
компании, занимающейся
разработкой и внедрением
информационных систем
Содержание
1. Введение
1.1. Назначение данного документа
1.2. Изменения данного документа
2. Определение проекта
2.1. Назначение проекта
2.2. Цели проекта
2.3. Необходимые условия для достижения
поставленных целей
3. Рамки проекта
3.1. Логические рамки проекта на момент его
начала
3.2. Временные рамки проекта
4. Организация и управление проектом
4.1. Организационная структура проекта
4.2. Распределение ролей участников проекта
4.2.1. Спонсор проекта
4.2.2. Управляющий Совет
4.2.3. Председатель Управляющего Совета
4.2.4. Руководители проекта
4.2.5. Группа внедрения
4.2.6. Состав группы внедрения
4.3. Документооборот проекта
4.3.1. Общие документы
4.3.2. Отчетные документы
4.3.3. Рабочие документы
4.3.4. Периодичность подготовки отчетной
документации
4.4. Процедура решения проблем
4.5. Подход к управлению изменениями рамок
проекта
5 Завершение проекта

65. Уровни проектирования

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

66. Уровни проектирования

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

67. Уровни проектирования

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

68. Структура основных и вспомогательных процессов планирования

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

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

70.

Диаграмма
зависимостей
процессов
для
управления
интеграцией

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

создания продукта

72. Три уровня будущего продукта

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

73. Результат этапа планирования содержания

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

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

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

75. Уточнение содержания

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

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

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

77. Процедуры процесса планирования

78. Шаги процесса планирования

79. SMART – подход к определению целей проекта

Цели проекта должны быть:
конкретными (Specific), т. е. определяющими, что
должно быть достигнуто и к какому сроку;
измеримыми (Measurable) посредством цены,
качественных и количественных параметров;
достижимыми (Attainable) в пределах знаний, опыта,
интенсивности потребления ресурсов и т.п.;
реалистичными (Realistic), т. е. достижимыми, но
требующими усилий;
контролируемыми (Trackable), т. е. согласованными
по датам и методам измерения достигнутого успеха.

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

81. Структуризация проекта

Основой для планирования и исполнения всего
проекта является разрабатываемая в ходе уточнения
содержания проекта иерархическая структура работ.
Методы структуризации:
«сверху-вниз» (дедуктивный метод top-down approach)
– определяются общие задачи, на основе которых
далее осуществляется детализация уровней проекта;
«снизу-вверх» (индуктивный метод bottom-up approach)
– определяются частные задачи, а затем происходит
их обобщение.

82. Уточнение содержания связано:

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

83. Структуризация проекта

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

84. Структуризация проекта

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

85. Структуризация проекта: WBS

86.

При построении ИСР необходимо соблюдать следующие принципы:
1. Работы нижнего уровня (дочерние) являются способом достижения работ верхнего уровня
(родительские).
2. У каждой родительской работы может иметься несколько дочерних работ, достижение
которых обеспечивает достижение родительской работы.
3. У каждой дочерней работы может быть только одна родительская работа.
4. Декомпозиция родительской работы на дочерние производится по единому
критерию, в качестве которого могут выступать:
компоненты результатов и продуктов проекта,
этапы жизненного цикла проекта,
ресурсы и функциональные виды деятельности
элементы организационной структуры.
5. На одном уровне дочерние работы, декомпозирующие родительскую должны быть
равнозначны. В качестве критерия равнозначности могут выступать: объем и время
выполнения работ и пр.
6. При построении иерархической структуры работ на различных уровнях можно и следует
применять различные критерии декомпозиции.
7. Последовательность критериев декомпозиции работ следует выбирать таким образом, чтобы
как можно большая часть зависимостей и взаимодействий между работами оказалась на самых
нижних уровнях ИСР. На верхних уровнях работы должны быть автономны.
8. Декомпозиция работ прекращается тогда, когда работы нижнего уровня удовлетворяют
следующим условиям:
работы ясны и понятны менеджеру и участникам проекта (являются элементарными),
понятен конечный результат работы и способы его достижения, временные характеристики
и ответственность за выполнение работ могут быть однозначно определены.

87. Задание

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

88. Задание

89. Структуризация проекта

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

90. Структуризация проекта

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

91. Структуризация проекта

Сетевые графики реализации проекта

92. Построение плана по вехам

После построения иерархической структуры работ и структурной схемы
организации проекта появляется возможность проставить и согласовать с
заказчиком основные этапы проекта (вехи)
Веха — событие или дата в ходе осуществления проекта. Веха
используется для отображения состояния завершенности тех или иных
работ.
Таблица – План по вехам
Показатели
СРОК
Январь
1
2
…..
Декабрь

93. Проектная документация

Задание на проектирование (техническое
задание).

94. Техническое задание

ТЗ — это документ, в котором фиксируются требования к
проекту.
Это не ТЗ, а поручение
Сходи, купи хлеб
Вот ТЗ
Мне нужен хлеб:
Купи его до 18:00 сегодня (дата).
Мне нужен хлеб из пекарни около дома.
Хлеб должен быть весом от 200 до 300 г.
Он должен быть из пшеничной муки 1 сорта
Другой хлеб мне не нужен.

95. ТЗ ИТ-проектов

ГОСТ 34.602—2020 Информационные технологии
КОМПЛЕКС СТАНДАРТОВ НА АВТМАТИЗИРОВАННЫЕ СИСТЕМЫ
Техническое задание на создание автоматизированной системы
В АС могут выделяться составные части (СЧ), для которых могут разрабатываться
ТЗ на составные части .
ТЗ на АС содержит следующие обязательные разделы:
- общие сведения;
- цели и назначение создания автоматизированной системы;
- характеристика объектов автоматизации;
- требования к автоматизированной системе;
- состав и содержание работ по созданию автоматизированной системы;
- порядок разработки автоматизированной системы;
- порядок контроля и приемки автоматизированной системы;
- требования к составу и содержанию работ по подготовке объекта автоматизации к
вводу автоматизированной системы в действие;
- требования к документированию;
- источники разработки.
В ТЗ на АС могут быть включены приложения.

96. Материально-техническое обеспечение проекта

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

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

98. Управление временем проекта

99. Управление временем проекта

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

100. Диаграмма Ганта

Диаграмма Ганта — это визуальное
представление графика работ,
построенное согласно плану
проекта. На ней отражены задачи и
последовательность их выполнения.
График работ состоит из ряда
отрезков, размещённых вдоль
временной оси. Каждый из них
соответствует отдельной задаче или
подзадаче. Начало и конец отрезка
соответствуют моменту начала и
завершения работы по задаче.
Длина отрезка — продолжительность
работ.
Диаграмма Ганта нужна, чтобы
наглядно представить все этапы
работы. Она показывает:
•задачи, включённые в проект;
•их продолжительность;
•даты начала и окончания проекта;
•время, которое занимает каждая
задача;
•исполнителей, работающих над
задачами;
•способы объединения задач.
Всё это позволяет оценить все
ресурсы и взаимосвязи задач.
А значит, запланировать работу так,
чтобы не пришлось глобально
пересматривать подход, менять
команду или инструменты.

101. Управление временем проекта: сетевая диаграмма предшествования типа АОN (Activity on node, работа в узле)

ABCD …-это работы

102. Управление временем проекта: стрелочная диаграмма типа АОА (Activity on arow, задача на стрелке)

103. PERT-оценка

(Program Evaluation Review Technique,
Техника Оценки и Анализа Программ)
PERT и метод критического пути – методики планирования работ, которые
используются для просмотра зависимостей задач и оценки сроков
выполнения проектов, для вероятной оценки времени работ. Обе
диаграммы визуально похожи, поскольку они обе сетевые.
Основное различие – в количестве параметров оценки. В диаграмме
критического пути используется один параметр для оценки сроков каждой
задачи, а в PERT-диаграмме их три: в наилучшем, наихудшем и наиболее
вероятном случае. Ввиду использования трех параметров на PERTдиаграммах отображается несколько потенциальных сроков выполнения
проекта.
СРМ (Critical Path MethoD)- для проектов с фиксир врем работ

104. PERT-оценка

Ранний старт
Продолжительность
Ранний финиш
Название задачи
Поздний старт
Резерв
Поздний финиш
В каждой рамке отображается операция или
задача проекта. В каждой рамке семь
секций с разной информацией о задаче:
В прямоугольнике посередине
отображается номер или название задачи.
В верхней левой рамке отображается
раннее начало (Early Start, ES), самый
ранний срок начала выполнения задачи.
В верхней средней рамке отображается
продолжительность выполнения задачи,
рассчитанная по методу PERT.
В верхней правой рамке отображается
раннее окончание (Early Finish, EF), самый
ранний срок окончания выполнения задачи.
В нижней правой рамке отображается
позднее окончание (Late Finish, LF), самый
поздний срок окончания выполнения
задачи.
В нижней средней рамке отображается
резерв времени для выполнения задачи без
влияния на дату окончания проекта.
В нижней левой рамке отображается
позднее начало (Late Start, LS), самый
поздний срок начала выполнения задачи.

105.

Проект состоит из ряда последовательностей, т.е. задач.
Ранний старт- это дата с которой можно начинать работу
Ранний финиш= Ранний старт + Продолжительность работы-1
Расчет ранних дат показывает продолжительность проекта, но не показывает приоритет задач. Для этого считаем
поздние даты
6
8д
13
14
5д
5-й
д
6
0
13
6
3д
8
1
0
14
0
20
14
6д
19
Задача 3
Задача 1
5
20
Задача 5
Задача 2
1
7д
21
Задача 6
12
6
14
6
6д
11
15
1
4д
24
ФИНИШ
Задача 7
20
21
0
24
Задача 4
15
9
20
Задачи 2,3,4 –параллельны, поэтому ранний старт у всех = 6-му дню
Поздний финиш – это дата когда может завершиться задача не меняя срок завершения проекта
Задача 7 – последняя, поэтому поздний финиш = 24
Поздний старт=Поздний финиш – Продолжительность +1
Ранний старт
Продолжительность
Позд. финиш по Зад 6, 5 и 4 = 20, т.к. Зад 7 = 21
Название задачи
Резерв = Поздний финиш – ранний финиш
Поздний старт
Резерв
Ранний финиш
Поздний финиш

106. PERT-оценка (техника)

1.
2.
3.
Начните с составления списка всех задач проекта.
Укажите зависимости задач.
Составьте таблицу с шестью столбцами:
Название или номер задачи
2.
Предыдущая задача (название или номер задачи, выполнение которой должно завершиться до
начала текущей задачи)
3.
Оптимистичный (наилучший) расчетный срок выполнения
4.
Средний расчетный срок выполнения задачи
5.
Пессимистичный (наихудший) расчетный срок выполнения
6.
Расчетное время
Оцените наилучший, наихудший и средний срок выполнения каждой задачи.
По формуле рассчитайте оценочные сроки выполнения:
1.
4.
5.
Т ожид = (наилучший минимальный срок + (4 x средний срок) + наихудший срок) / 6

107. PERT-оценка (техника, продолжение)

1.
2.
3.
4.
5.
6.
Заполняйте названия задач слева направо в установленном порядке на основе названий предыдущих задач.
Используйте расчетное время для внесения в таблицу продолжительности выполнения.
У первой задачи раннее начало (ES) будет равно 0, поскольку это самое начало работы. Раннее окончание (EF) =
ES + продолжительность.
ES следующей задачи = EF предыдущей задачи. Заполните эти две рамки слева направо для каждой задачи.
Если рамка связана с двумя и более предыдущими задачами, ее ES = наиболее позднее из всех связанных EF
(например, если EF задачи A = 2, EF задачи B = 4, а обе нужно выполнить до начала задачи C, то самое ранее
начало задачи C = 4).
После внесения последней задачи ее EF становится ее поздним окончанием (LF, Late Finish) — это наибольшая
продолжительность проекта.
Теперь заполняйте рамки справа налево: рассчитайте все LF и LS.
Из последнего внесенного LF вычтите продолжительность для расчета LS задачи.
2.
Для внесения LS используйте LF предыдущей задачи.
7. Последний параметр для расчета – это резерв времени. Резерв времени = LF – EF. Он отражает, на сколько
времени можно отложить задачу от запланированной даты начала без срыва общих сроков.
8. Если у задачи резерв времени = 0, то эта задача вышла на критический путь. Вы можете выделить ее другим цветом
для привлечения внимания.
1.

108. Расчёт расписания проекта

109. Корректировка расписания проекта

110. Оценка стоимости проекта

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

111. Управление стоимостью проекта

112. Управление стоимостью проекта

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

113. Процессы управления стоимостью проекта

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

114.

Планирование бюджета проекта
Процесс формирования, учета и контроля выполнения
бюджетов называется бюджетированием.
Виды оценок стоимости
Оценка
Допустимая
погрешность
использования
-25%
+75%
Концептуальная (начальная). Без
точных данных.
Бюджетная. На основе информации об оборудовании,
материалах. Для получения финансовых средств.
Точная
(тендерная,
контрольная).
На
основе
спецификаций. Для договоров, контрактов, контроля.
-10%
+25%
-%5
+10%

115. Смета проекта

Смета – это перечень расходов, структурированный по разделам, но без
привязки к календарному плану проекта.
ВИДЫ СМЕТ, СОСТАВЛЯЕМЫХ НА РАЗНЫХ СТАДИЯХ
ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА.
Стадии проекта
Стадии проекта
Вид сметы
Инициация
Исследование
инвестиционных
возможностей
ТЭО
Предварительная
(локальная)
Планирование
Назначение сметы
Погрешнос
ть
25-40%
Оценка
жизнеспособности
проекта
Первичная
или Сравнение
15-25%
факторная
планируемых
(объектная)
затрат
с
бюджетными
ограничениями
Начальная стадия Приближенная
Подготовка плана 10-15%
рабочего
(сметы
на финансирования
проектирования
отдельные затраты) проекта
Разработка
Сводная
смета Ценообразование
5-6%
рабочего проекта проекта

116. Структура сводного сметного расчета проекта

Локальная смета — первичный документ, содержащий
расчеты и оценки стоимости конструктивных элементов и
видов работ по проекту в текущих или прогнозных ценах.
В локальную ресурсную ведомость включают:
•затраты труда сотрудников (человеко-часы);
•время использования техники (машино-часы);
•расход материалов, изделий, конструкций и т. д. (в
принятых физических единицах измерения).
Сметы на отдельные виды затрат— документы,
содержащие расчеты и оценки стоимости по затратам,
не учтенные сметными нормативами:
-премирование за досрочное завершение проекта;
-оплату консультационных, аудиторских услуг;
-выплаты льгот и компенсаций и др.
Объектная смета — документ, содержащий расчеты и оценки стоимости по объекту (объектам) в целом в базисных или текущих
ценах.
•Цена базисная — цена товара стандартного качества, на основе которой устанавливается цена товара более высокого и
низкого качества, например в случае, когда свойства фактически поставленного товара отличаются от оговоренных в контракте.
•Цена текущая — цена или тариф, действующие в данный период времени (могут быть оптовые, закупочные, розничные, цены и
расценки в строительстве, тарифы и цены на услуги, оказанные предприятиям, организациям, населению).
По итогам разработки объектной сметы проекта команда управления проектом и заказчик могут получить показатели единичной
стоимости объекта:
•стоимость 1 кв. м площади (например, жилой или офисной);
•стоимость 1 куб. м объема (например, возводимой конструкции) и пр.
Сводный сметный расчет — основной документ, определяющий стоимость проекта, обобщающий данные локальных и
объектных смет и смет на отдельные виды затрат, в базисных и текущих ценах или в базисных и прогнозных ценах.
В сводном сметном расчете происходит суммирование и сведение воедино данных локальных и объектных смет до уровня
всего проекта. В итоговый сметный расчет включаются данные смет на отдельные виды затрат.
К сводному сметному расчету (сводной смете) обычно прилагается пояснительная записка, которая содержит сопутствующую
информацию, необходимую для понимания документа и облегчения работы с ним.

117. Бюджет проекта

Бюджет – это директивный документ, представляющий собой график
планируемых расходов и доходов, распределенных по статьям в рамках
проекта.
ВИДЫ БЮДЖЕТОВ
Назначение бюджета Погреш
ность
Предварительный Обоснование статей 15-20%
бюджет
затрат, планирование
привлечения
Планировафинансовых средств
ние
Базовый бюджет
5-8%
Разработка
Ограничение
рабочей
использования
документации
ресурсов
Реализация проекта
Текущий бюджет Отражение
3-5%
отклонений от плана
и их корректировка
Завершение проекта
0-3%
Бюджет
по Управление
завершении
стоимостью (учет и
контроль)
Стадии
проекта
Инициация
Этапы
проекта
Обоснование
инвестиций
ТЭО
Вид бюджета

118. Оценочные затраты

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

119. Уменьшение стоимости работ

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

120. Процесс планирования бюджета проекта включает три этапа

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

121. Методы оценки стоимости работ проекта

•Параметрическая оценка —для стоимостной оценки используется статистическая зависимость между стоимостью
операции и другими переменными (параметрами), полученная на основе анализа исторических данных (например,
величина площади конструкции в строительстве, число строк в коде программы, количество часов рабочего
времени). Опытным путем рассчитывается стоимость одной единицы объема работ. Например, стоимость
строительства 1 кв. м жилья, 1 часа работы эксперта и др.
•Оценка по аналогам — метод оценки стоимости по аналогии со сходными работами, выполнявшимися в этом или
других проектах. Метод оценки по аналогам может относиться ко всему пакету работ целиком или использоваться в
комплексе с параметрической оценкой, когда имеется информация о выполнении аналогичных работ, но другого
объема или в других условиях.
•Оценка «снизу вверх» — технология оценки больших объемов работ суммированием оценок, полученных для
более мелких составляющих данной работы. Чем более подробно и точно разработана ИСР проекта, тем точнее и
корректнее могут быть получены стоимостные оценки по проекту. Метод «снизу вверх» по праву считается одним из
самых точных.
Пример Перед передачей нового сервера заказчику его необходимо протестировать. Стоимость
тестирования сервера может быть определена способом «снизу вверх». Это будет сумма стоимостей:
•штатного тестирования;
•стресс-тестов;
•нагрузочного тестирования в термокамере.
•Метод оценки «сверху вниз» считается значительно менее точным по сравнению с методом «снизу вверх». Он
применяется в условиях отсутствия детальной ИСР, нехватки информации о ресурсах и материалах, необходимых
для реализации работ. Технология оценки предполагает ровно обратные шаги по отношению к методу «снизу вверх».
Сначала дается укрупненная оценка всего пакета работ, а затем она детализируется и декомпозируется на
отдельные элементы (по работам, исполнителям и др.). Метод имеет право на жизнь на ранних этапах проекта, когда
выполняется оценка его жизнеспособности и непонятно, следует ли расходовать ресурсы на более детальное
планирование и оценку.
•Анализ предложений исполнителей — очень простой метод при условии наличия исполнителей и подрядных
организаций, желающих выполнить данный объем работ. Техническое задание, тендерная или иная документация
рассылается по исполнителям-претендентам с просьбой предоставить свои оценки стоимости (а зачастую — и
продолжительности) выполнения данных работ.

122. Чем отличается бюджет от сметы?

1) бюджет составляются с разбивкой по годам, кварталам и/или месяцам, а
смета составляется на конкретный объём работ (процесс), с указанием
только конечной даты исполнения работ;
2) бюджет относится к документам, через систему которых осуществляется
контроль над деятельностью конкретных руководителей и менеджеров, а
при помощи сметы отслеживается исполнение отдельных операций,
предусмотренных технологическим процессом;
3) бюджеты представляют собою либо балансы затрат и доходов (расходы —
приходы), либо целенаправленные календарные планы (только по
расходам или только по приходам), в зависимости от пользователя
информации. Сметы же представляют собой описи планируемых работ, их
количество, стоимость и применяемое оборудование;
4) в течение года бюджеты могут корректироваться с учётом сложившихся
обстоятельств, а сметы не корректируются;
5) в деятельности любой компании есть место и бюджету, как инструменту
управления выделенными средствами, так и смете, используемой в
качестве показателя обеспечения финансирования процессов.

123. Подходы оценки проектов по внедрению ИТ

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

124. Эффективность ИТ - проектов

Существует много методик по оценке эффективности инвестиционных проектов.
1Учетные (статические) методы оценки эффективности (ROI, PP, ARR).
Они не включают в себя динамический аспект, который влияет на конечную стоимость,
и, как следствие, эффективность инвестиционного проекта, но дают возможность
обеспечить первоначальную оценку и отказ от наименее стоящих идей вложения
средств.
2 Динамические (дисконтированные) методы оценки эффективности (NPV,
IRR, DPP)
PI,
Суть их расчета заключается в приведении будущих денежных потоков (стоимости
денег) к «сегодняшнему» дню, вернее, к моменту начала инвестиций в проект.
Приведение денежных потоков называется дисконтированием.
Ставка дисконтирования — это минимальная ставка дохода, при которой инвестор
согласен вкладывать деньги в рассматриваемый проект.

125. Новые финансовые методики оценки эффективности ИТ-проектов

Расчет совокупной стоимости владения – TCO (Total Cost of Ownership)
С точки зрения TCO – существуют так называемые «прямые» или «бюджетные» расходы и
«неявные» (скрытые или небюджетируемые) затраты в содержание «своей» информационной
системы, затраты и потери, связанные с ее функционированием и так далее
В рамках методики TCO при расчете затрат на создание и эксплуатацию ИТ-инфраструктуры
учитываются следующие «прямые затраты»:
Оборудование и программное обеспечение
Затраты на ИТ-персонал
Затраты на каналы связи, сервисы сети Интернет и электронного обмена данными
Небюджетируемые – «непрямые затраты» – связанны с эксплуатацией ИТ-инфраструктуры,
но не имеют статьи в бюджете предприятия:
Самообучение пользователей работе со своим компьютером и набором программного
обеспечения, обучение коллег и помощь им.
Самостоятельное обслуживание пользователем своего компьютера и набора программ –
резервное копирование, восстановление после сбоя, отладка программ, установка
драйверов новых устройств и т.д.
Использование служебных компьютеров и информационных систем для «работы на
сторону», для развлечения, игр и т.п.
Простои в работе информационной системы и другие.

126. Новые финансовые методики оценки эффективности ИТ-проектов

Расчет совокупной стоимости владения – TCO (Total Cost of Ownership)
Формулы расчета непрямых затрат
Стоимость потерь в производительности сотрудников
Оценочная стоимость времени, работников, на которых влияет простой и которые не могут
работать как обычно.
Cвремя сотрудников = W * E * t
Где W – средняя оплата труда работника в час, E – количество сотрудников, а t – время
простоя в часах.
Стоимость восстановления ИТ-инфраструктуры
Стоимость времени ИТ-персонала, занятого восстановлением вашей системы из
резервной копии или заменой вышедшего из строя оборудования.
Cвосстан Ит = W * Eit * t’
где W – средняя оплата труда работника в час, EIT – число IT-специалистов, а t’ – время,
которое требуется для исправления неисправностей и возврата инфраструктуры к
рабочему состоянию.

127.

Прогнозируемая потеря дохода из-за снижения лояльности клиентов
Для простоты давайте предположим, что рассматриваемый бизнес не является широко освещаемым
средствами массовой информации, поэтому прогнозируемый потерянный доход рассчитаем на основе потери
возможных повторных продаж.
Где r- обозначает средний показатель (rate, процент) снижения повторных продаж, а Д — доход от повторных
продаж за год.
Прогнозируемая потеря дохода из-за ущерба репутации
Потерянные продажи клиентам, исследующим рынок в поиске лучшей сделки или собирающим рекомендации.
Где r' обозначает процент снижения продаж, связанный с клиентами, пришедшими с сайтов с отзывами для
сравнения товаров/услуг и из социальных сетей.
Прямые потери дохода от продаж
Это может показаться тривиальным, но предполагая, что доход генерируется онлайн или строго зависит от
работы ИТ, вам потребуется просто разделить сумму годовых продаж на 525 600 (60 мин. X 24 часа x 365 дней)
и умножить на количество минут простоя вашей IT-инфраструктуры
Упродаж = (Годовой доход / 525 600) * t
Таким образом, формула общей стоимости простоя (TCoDT, total cost of downtime) может выглядеть примерно
так:

128. Проектная документация

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

129. Типы документации для ИТ-проектов

Существует четыре основных типа документации на ПО:
• архитектурная/проектная – обзор программного обеспечения, включающий
описание рабочей среды и принципов, которые должны быть использованы при
создании ПО.
Проектная документация обычно описывает продукт в общих чертах. Не описывая того, как что-либо будет использоваться, она
скорее отвечает на вопрос «почему именно так». Например, в проектном документе программист может описать обоснование
того, почему структуры данных организованы именно таким образом. Описываются причины, почему какой-либо класс
сконструирован определённым образом, выделяются паттерны, в некоторых случаях даже даются идеи как можно будет
выполнить улучшения в дальнейшем.
• техническая – документация на код, алгоритмы, интерфейсы, API.
При создании программы, одного лишь кода, как правило, недостаточно. Должен быть предоставлен некоторый текст,
описывающий различные аспекты того, что именно делает код. Такая документация часто включается непосредственно в
исходный код или предоставляется вместе с ним.
• пользовательская – руководства для конечных пользователей, администраторов
системы и другого персонала.
Обычно, пользовательская документация представляет собой руководство пользователя, которое описывает каждую функцию
программы, а также шаги, которые нужно выполнить для использования этой функции. Хорошая пользовательская
документация идёт ещё дальше и предоставляет инструкции о том, что делать в случае возникновения проблем. Очень важно,
чтобы документация не вводила в заблуждение и была актуальной. Руководство должно иметь чёткую структуру; очень
полезно, если имеется сквозной предметный указатель. Логическая связность и простота также имеют большое значение.
• маркетинговая. Для многих приложений необходимо располагать рядом с ними рекламные материалы, с тем, чтобы
заинтересовать людей, обратив их внимание на продукт. Такая форма документации имеет целью:
-подогреть интерес к продукту у потенциальных пользователей
-информировать их о том, что именно делает продукт, с тем, чтобы их ожидания совпадали с тем, что они получат
-объяснить положение продукта по сравнению с конкурирующими решениями.
Одна из хороших маркетинговых практик — предоставление слогана — простой запоминающейся фразы, иллюстрирующей то,
что необходимо донести до пользователя, а также характеризующей ощущение, которое создаёт продукт.

130. Управление рисками проекта

ГОСТ Р 56275-2014 Национальный стандарт РФ МЕНЕДЖМЕНТ РИСКОВ.
Руководство по надлежащей практике менеджмента рисков проектов
ГОСТ Р 58771-2019 Национальный стандарт РФ МЕНЕДЖМЕНТ РИСКА.
Технологии оценки риска
ГОСТ Р 58970-2020 Национальный стандарт РФ "МЕНЕДЖМЕНТ РИСКА.
Количественная оценка влияния рисков на стоимость и сроки
инвестиционных проектов"
Риск – это неопределенное событие или условие, наступление которого
отрицательно или положительно сказывается на целях проекта, таких как
содержание, расписание, стоимость и качество. Причем влияние риска на
проект может быть, как отрицательным, так и положительным. На практике
риски рассматриваются как угроза проектам.
Причины рисков проекта находятся в неопределенности, которая присутствует
во всех проектах.
Известные риски – это те риски, которые были идентифицированы и
проанализированы, что позволяет планировать реагирования на них. Для тех
известных рисков, которыми невозможно управлять проактивно, следует
выделить резерв на возможные потери.
Неизвестными рисками невозможно управлять проактивно, и, следовательно,
для них можно выделить управленческий резерв.
Наступивший отрицательный риск проекта рассматривается как проблема.

131. Виды ИТ-рисков

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

132.

133. Управление рисками проекта

Действия по управлению рисками
1. Планирование управления рисками – этот процесс должен определить правила и
подходы к управлению рисками проекта
2. Идентификация рисков - процесс определения перечня рисков, которые
могут воздействовать на проект, и документирования их характеристик. К
3. Качественный анализ рисков - процесс расстановки приоритетов в
отношении рисков для их дальнейшего анализа или действий, выполняемый путем
оценки и сопоставления их воздействия и вероятности возникновения.
4. Количественный анализ рисков - процесс численного анализа воздействия
идентифицированных рисков на цели проекта в целом
5. Планирование реагирования на риски
6. Контроль рисков.

134. Управление проектной командой

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

135. Основные функции проект-менеджера

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

136. Основные функции проект-менеджера

Создание команды. Целевой подбор участников.
Распределение функций и ответственности.
Применение стимулов. Создание благоприятного
психологического климата. Правильная оценка
результатов работы участников команды.
Руководство командой. Быть примером. Быстрота
реагирования и действий. Делегирование
полномочий. Контроль работы членов команды.
Помощь и поддержка членов команды. Умение
убеждать в правильности принятых решений.
Разрешение межличностных конфликтов.

137. Основные функции проект-менеджера

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

138. Управление проектной командой

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

139. Стадии формирования проектной команды

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

140. Стадии формирования проектной команды

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

141. Структура системы управления командой проекта

1.
2.
3.
Формирование и развитие команды: формирование
организационной структуры; закрепление зон ответственности
и полномочий; назначение проект-менеджера и менеджеров на
ключевые посты; организационное развитие команды.
Организация деятельности команды: организация
совместной деятельности; формирование и развитие
организационной, деловой и корпоративной культуры;
организация коммуникаций и офиса команды; организация
принятия решений; организация совещаний; организация
переговоров.
Управление персоналом команды: стратегия управления
персоналом; кадровое планирование; развитие кадров;
система мотивации, стимулирования и вознаграждений;
социально-психологическая работа; кадровый учет;
управление рабочим временем.

142. Основные принципы формирования команды проекта

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

143. Основные принципы формирования команды проекта

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

144. Основные подходы к формированию команды

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

145. Основные подходы к формированию команды

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

146. Качества командной работы

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

147. Активная фаза формирования проектной команды

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

148. Виды последствий конфликтов

Деструктивные
Конструктивные
• снижение эффективности
работы; ослабление духа
сотрудничества; появление
непродуктивной
конкуренции.
• выработка альтернативных
эффективных решений;
продуктивная конкуренция;
устранение враждебности и
нацеленность на достижение
общего результата.

149. Методы управления конфликтами

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

150. Офис проекта (ОП)

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

151. Функции офиса проекта

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

152. Контроль и регулирование проекта

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

153. Виды контроля

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

154. Контроль и регулирование проекта

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

155. Контроль и регулирование проекта

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

156. Контроль и регулирование проекта

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

157. Процессы контроля

158. Корректирующие действия

найти альтернативное решение;
пересмотр стоимости;
пересмотр сроков;
пересмотр содержания работ;
прекращение проекта.

159. Управление изменениями проекта

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

160. Управление изменениями проекта

1. Описание. На начальной стадии необходимо уяснить и описать
предлагаемое изменение. Предложение документируется и обсуждается.
2. Оценка. Вторая стадия предусматривает полномасштабный анализ
влияния предлагаемого изменения. Для этого производится сбор и
согласование всей информации, необходимой для оценки последствий
данного изменения. Результаты исследования документируются и
обсуждаются.
3. Одобрение. Рассматриваются результаты исследований и принимается
решение: одобрить изменение, отказать, отложить. Если принято
решение отложить реализацию изменения, то необходимо провести
дополнительные исследования и расчеты. Если принимается
положительное решение, то утверждаются исполнители и выделяются
средства на проведение изменения. Принятые решения
документируются.
4. Реализация. Изменение вносится в план проекта и реализуется.
5. Подтверждение исполнения. Контроль корректного и полного выполнения
работ в рамках данного изменения.

161. Управление коммуникациями

Планирование
коммуникаций
Распространение
информации
Отчетность об
исполнении

162. Административное завершение проекта

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

163. Операции по завершению проекта

164.

СПАСИБО ЗА ВНИМАНИЕ