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

1.

О С Н О В Ы У П РА ВЛ Е Н И Я П РО Е К ТА М И
- базовые понятия управления проектами -

2.

Типы проектной деятельности:
1. Операционная (постоянная)
2. Проектная (временная)

3.

Критерии успешности проекта
1. Справились в заявленные сроки
2. Смогли влезть в тот бюджет, который был
запланирован
3. Выполнили требования заказчика –
заказчик удовлетворен

4.

Проектный треугольник

5.

Техноогические
Уровень
ществующи
х
Наличие
новых
хнологий
Факторы внешней среды
Ресурсообеспеченность
Экономические
Наличие
Инфляция
Доступ
Ограничения
государственного
Социальные
Экологические
Конкурент
Лицензирован
ие
Традиции
Уровень
загрязнения
Количеств
Уровень
безработицы
Мероприятия
по
охране
окружающей
среды
Возможнос
сектора
Налоги
Закон о
творчество

6.

При разработке деловой стратегии
используют три основных подхода:
Лидерство в
издержках
Функциональную
стратегию
Дифференциацию
Концентрацию на
определенных
направлениях

7.

Международные стандарты
1. Управление проектами
2. Стандарты и рекомендации
3. Общий язык и взаимодействие
4. Системная картина
5. Сертификация

8.

* Три основные роли *
Заказчик
проекта
Менеджер
проекта
Куратора
проекта

9.

10.

Этапы проекта
Этапы унификации, к которой можно
стремиться для получения результата:
• Предпроект
• Запуск
• Планирование
• Выполнение
• Закрытие

11.

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

12.

Метод SMART
S
•SPECIFIC
– чёткая
M
•MEASURABLE
– измеримая
A
•ACHIEVABLE
– достижимая
R
•REALISTIC
– реалистичная
T
•TIME-BOUNDED – ограниченная по
времени

13.

Действия для запуска проекта
o Оценка выполнимости проекта
o Официальный выбор руководителя
o Определение целей проекта
o Выбор стейкхолдеров
o Сбор ключевых требований со
стейкхолдеров
o Оценка базовых рисков, критериев
успешности

14.

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

15.

Группы стейкхолдеров:

16.

Выявление
проблемы:
Анализ
требований:
Спецификация:
Проверка
реализации:
Область проблем
и решений:
Начинается с поиска
проблемы, которую
заказчик и его команда
испытывают
Анализ требований.
Формулирование
требований так, чтобы
их можно было
дальше реализовывать
Создается
специальный
документ, в котором
требования
ранжируются и
приоритезируются
Проектный менеджер
проверяет, насколько
требование было
реализовано
Проектный менеджер
и его команда
обладают множеством
идей и решений,
связанных с
конкретной отраслью
или технологией
Проектный менеджер
должен понять, что
именно беспокоит
заказчика и какую
проблему он хочет
решить
Требования могут
быть
задокументированны,
так и не
задокументированны
Этот документ
становится основой
для дальнейшей
работы
Если всё готово,
можно сообщить
заказчику о
завершении
Однако, если сразу
предложить решение
заказчику, мы можем
упустить реальную
проблему, которая у
него есть
Важный вопрос:
Прежде чем
переходить к анали
и спецификации
ответьте на вопро
“Что конкретно
заказчика болит
Какую реальную
проблему он
пытается решить

17.

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

18.

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

19.

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

20.

Диаграмма контрольных точек
(Майлстоун-чарт):

21.

Диаграмма Гантта:

22.

Алгоритм составления расписания
Определение целей и
задач проекта
• Четкое определение целей и задач проекта поможет понять, какие
операции необходимо выполнить для достижения
этих целей.
Идентификация зависимостей
между операциями
• Определение логических связей между операциями (предшествование,
последование) поможет построить последовательность выполнения
работ.
Оценка времени выполнения
операций
• На основе опыта, экспертных оценок или исторических данных
определите ожидаемое время выполнения каждой операции
Распределение ресурсов
• Определите необходимые ресурсы для каждой операции (люди,
материалы, оборудование) и убедитесь, что они доступны в нужное время
Построение графика проекта
• Используйте специализированные инструменты (например, MS Project)
для создания графика проекта, отражающего последовательность
операций, зависимости между ними, ресурсы и сроки выполнения
Мониторинг и контроль
• Регулярно отслеживайте выполнение работ по графику, корректируйте
план при необходимости, управляйте рисками и ресурсами для успешного
завершения проект

23.

Необходимо оценивать ресурсы
Типы оценок:
1. Оценка по аналогам
(Является не очень точной оценкой)
2. Экспертная оценка
3. Параметрическая оценка
(Математическое моделирование)
4. Оценка по трем точкам, PERT

24.

Метод оценки длительности операций в
проекте, известный как PERT
оптимистическая (O)
пессимистическая
(P)
средняя (M)
T = (O + 4M + P) / 6.

25.

Три резерва
1. Уровень операций
Когда вы их оценивали, вы, скорее всего, гдето допустили ошибку.
2. ИСР
Это те самые 10%.
3. Уровень менеджера
Когда мы всё просчитали по операциям, по
пакетам работ, заложили резерв на риски и
заложили менеджмент-резерв, мы считаем, что
бюджет проекта у нас присутствует. Это
себестоимость.

26.

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

27.

Матрица ответственности (RACI)

28.

Алгоритм управления рисками
1
Планирование
управления
рисками
7
Мониторинг
2
Идентификация
рисков проекта
6
Реагирование на
риски
3
Качественный
анализ
5
Планирование
рисков проекта
4
Количественный
анализ

29.

RBS (Иерархическая структура рисков)

30.

Метод Дельфи
o Рассылаем запросы
экспертам, которые
не знают друг друга.
o Эксперты
присылают нам
свои ответы.
o Мы объединяем их
в единый реестр и
отправляем на
согласование.

31.

Метод качественного анализа рисков

32.

Пять стратегий реагирования на риски
Ук л о н е н и е
• Мы меняем план проекта, чтобы само возникновение
риска стало невозможным.
Пе редача
• Мы ничего не делаем с вероятностью риска. Но при этом
думаем, как воздействие переложить на третью сторону,
чтобы третья сторона отвечала за этот процесс.
Снижение риска
• Является самой распространенной и может применяться
к любому риску, так как подразумевает уменьшение
вероятности или влияния риска на проект
Стратегия принятия
• Команда не изменяет план управления проектом, не
способна определить иную стратегию реагирования
Э с к а л а ц и я р и с ко в
• Команда эскалирует наверх для принятия решения