Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Программное обеспечение управления проектами. Учебник
.pdf
ГЛАВА 1. БАЗОВЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
21
При реализации ИТ-проекта на практике состав участников проекта
может быть иным и включать другие роли, а функции участников и схе
мы их взаимодействия могут существенно отличаться от приведённой
в ГОСТ модели.
В проектах, выполняемых сторонними исполнителями для заказчика,
участвуют две равнозначные с точки зрения управления проектом организации. В таких проектах формируются две команды и обычно присутствует два руководителя проекта: один со стороны исполнителя, второй
со стороны заказчика. Возникает «двой ственная» (dual) организационная
структура управления проектом (рис. 1.10). В рамках двой ственной структуры команды взаимодействуют друг с другом, проводят оперативные
совещания с участием руководителей проектов от каждой стороны.
-
Рис. 1.10. Организационная схема проекта с участием двух команд
Кроме интересов субъектов управления важно учитывать и интересы
внешних заинтересованных сторон (стейкхолдеров, от англ. Stakeholder – «держатель интереса») проекта.
Стейкхолдеры рассматриваются в контексте процесса принятия решений как люди или организации, которые зависят от результатов принятых
решений. В управлении проектами стейкхолдерами могут быть отдельные лица, группы или организации, которые могут влиять или интересы
которых могут быть затронуты деятельностью или результатом проекта.
Стейкхолдеры в проектном управлении – это заинтересованные стороны, которые могут влиять на проект или быть затронутыми его результатами. Они могут включать в себя клиентов, поставщиков, сотрудников,
инвесторов, регулирующие органы и другие группы или лица.
Стейкхолдеры играют важную роль в проектном управлении, поскольку они могут оказывать влияние на успех или неудачу проекта. Их
потребности, ожидания и интересы должны быть учтены и удовлетворены
в процессе управления проектом:
Программное обеспечение управления проектами
22
1. Клиенты – являются основными стейкхолдерами, поскольку их потребности и ожидания определяют цели проекта. Клиенты могут быть
внутренними (например, другие отделы в компании) или внешними
(например, конечные пользователи продукта или услуги).
2.
Поставщики – предоставляют ресурсы, необходимые для выполнения проекта. Поставщики могут быть внутренними (например,
другие отделы в компании) или внешними (например, поставщики
оборудования или услуг).
3.
Сотрудники – выполняют работу по проекту. Сотрудники могут быть
членами команды проекта или другими сотрудниками, которых затронул проект.
4.
Инвесторы – предоставляют финансирование для проекта. Инвесторы
могут быть внутренними (например, руководство компании) или
внешними (например, банки или венчурные капиталисты).
5. Регулирующие органы – устанавливают правила и нормы, которым
должен следовать проект. Регулирующие органы могут быть государственными (например, правительственные агентства) или отраслевыми (например, профессиональные ассоциации).
Учет интересов и потребностей стейкхолдеров помогает обеспечить
успешное выполнение проекта и удовлетворение всех заинтересованных
сторон. Заинтересованные стороны могут прямо или косвенно влиять
на проект, его эффективность или результат как положительным, так
и отрицательным образом. Они могут находиться на различных уровнях
внутри организации и иметь разные уровни полномочий либо могут являться внешними по отношению к исполняющей проект организации.
В соответствии с PMBOK 7 заинтересованными сторонами (стейкхол-
дерами) проекта могут быть отдельные лица, группы или организации, которые могут влиять на проект или интересы которых могут быть затронуты
в ходе выполнения проекта или в результатом проекта, программы или
портфолио. Заинтересованные стороны могут прямо или косвенно влиять
на проект, его эффективность или результат, при этом влияние может быть
как положительным, так и отрицательным. Стейкхолдеры могут обладать
разными полномочиями и находиться на разных уровнях внутри или быть
внешними по отношению к организации – исполнителю проекта.
Состав и вовлеченность стейкхолдеров может меняться на протяже-
нии жизненного цикла проекта. Стейкхолдеры, обладающие высокой
степенью влияния и имеющие неблагоприятное или нейтральное мнение
о проекте, должны быть эффективно вовлечены, чтобы их интересы,
проблемы и права были поняты. Проектная группа может решить эти
проблемы путем эффективного взаимодействия и поддержки, что повысит вероятность успешного завершения проекта.
ГЛАВА 1. БАЗОВЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
23
Управление качеством проекта представляет собой деятельность,
направленную на достижение соответствия результатов проекта выявленным потребностям и ожиданиям. Качество – это целостная совокупность
характеристик объекта, относящихся к его способности удовлетворять
установленные или предполагаемые потребности 1.
Принято различать следующие аспекты качества: качество, обусловленное соответствием результатов проекта рыночным потребностям и ожиданиям; качество разработки (проектных решений) и планирования проекта; качество выполнения работ по проекту в соответствии с проектной
и плановой документацией; качество ресурсного обеспечения. Требования
к качеству проектных решений представлены в специализированных доку
ментах: стандарты (ГОСТ Р, ГОСТ, межгосударственные и международные
стандарты, правила, нормы и рекомендации по стандартизации, стандарты организаций и своды правил); нормативно- технические документы;
технические задания и ТУ; проектная и технологическая документация;
регламентации и соглашения сторон (договоры или контракты).
Качество проектной организации и создаваемого в ней продукта
непосредственно связано с уровнем системы менеджмента качества
(СМК), действующей в компании на момент проектной реализации.
Традиционные области управления проектами так или иначе связаны
с отклонениями – рисками, проблемами и изменениями, что отражено
на рисунке 1.11.
Рис. 1.11. Стадии, связанные с отклонениями в проекте
2
Полный цикл управления отклонениями выглядит следующим образом. При планировании проекта был идентифицирован риск, на возникновение которого не удалось повлиять. При наступлении рискового
события появилась проблема, которая также не была успешно решена.
В результате возникла необходимость внесения изменений в базовый
план проекта. Последовательно рассмотрим процессы работы с рисками,
проблемами и изменениями.
1
Руководство к своду знаний по управлению проектами (Руководство PMBOK®)
+ Agile: практическое руководство. – URL: https://litres.ru/pages/biblio_
book/?art=44774691 (дата обращения: 24.07.2023). – Режим доступа: Библиотека
ЛитРес.
2
Управление проектами в современной организации: учебно- методическое пособие /
Г. Л. Ципес, А. С. Товб, М. И. Нежурина, М. Г. Коротких. – Москва: Изд. дом НИТУ
«МИСиС», 2019.
–
264 с.
Программное обеспечение управления проектами
24
Риск проекта – это неопределённое событие или условие, которое
в случае возникновения имеет позитивное или негативное воздействие
по меньшей мере на одну из целей проекта (например, сроки, стоимость,
содержание или качество). Рисковое событие может оказывать как отрицательное, так и положительное влияние на проект. Качественная или
количественная оценка такого влияния носит название степени угрозы
и выражается через вероятность наступления рискового события и влияния его последствий на конечный результат проекта.
При определении рисковых событий, имеющих для проекта катастрофические последствия, важно учитывать уровни допустимой величины риска, риск-аппетита и толерантности к рискам, установленные
компанией.
Допустимая величина риска (risk capacity) – это максимальная сумма
потерь, которую организация может выдержать, прежде чем успешное
достижение целей проекта окажется под вопросом.
Риск-аппетит (risk appetite) – это уровень отклонения от цели, который организация готова принять для достижения своих стратегических
целей или других выгод.
Толерантность к риску (risk tolerance) – это границы принятия риска,
которые проект в состоянии пережить без критических последствий,
связанных с достижением целей.
Риск характеризуется вероятностью наступления и последствиями
воздействия на проект, классифицировать риски можно по разным основаниям (рис. 1.12).
Рис. 1.12. Виды рисков
Можно выделить несколько характеристик риска: причина или источник; симптомы; последствия; влияние. Процессы управления рисками
проходят по логической цепочке, представленной на рисунке 1.13.
ГЛАВА 1. БАЗОВЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
Рис. 1.13. Процессы управления рисками
25
Управление рисками в проекте должно выполняться на протяжении
всего его жизненного цикла. Чем ближе проект к завершению, тем сложнее осуществлять управление рисками и тем существеннее ущерб, связанный с наступлением рискового события. Деятельность по управлению
рисками в проекте требует дополнительных затрат времени и ресурсов,
и, следовательно, эта деятельность должна планироваться. Планирование
управления рисками – это процесс структурирования, определения подходов и планирования мероприятий по управлению рисками проекта.
Планирование управления рисками проекта необходимо для определения проблемных точек; анализа рисковых событий и снижения эффекта от их воздействия; повышения вероятности успешного достижения
результатов проекта.
План управления рисками включает в себя элементы, представленные
на рисунке 1.14.
Рис. 1.14. Основные составляющие плана управления рисками
Идентификация рисков – это выявление и определение характеристик
возможных рисковых событий, способных повлиять на проект, и их документирование. Процесс идентификации рисков является итеративным,
он периодически повторяется на протяжении всего жизненного цикла
проекта. Источниками исходных данных для выявления и описания характеристик рисков могут выступать следующие источники: база знаний
Программное обеспечение управления проектами
26
организации (архив предыдущих проектов); информация из открытых
источников, научных работ; маркетинговая аналитика; исследовательские работы в данной области; допущения проекта и связанная с ними
неопределённость, а также другие источники, доступные организации.
Систематическая и всесторонняя идентификация рисков проекта
с нужной степенью детализации проводится на основе классификации рисков. Классифицировать риски можно путем составления их иерархической структуры или перечня различных составляющих проекта
(процессы, команда, окружение и пр.). Пример классификации рисков
ИТ-проекта приведен на рисунке 1.15.
Рис. 1.15. Иерархическая структура рисков ИТ-проекта
(вариант классификации)
После идентификации рисков проводится их качественный и количественный анализ.
Качественный анализ рисков – это процесс приоритизации (ранжирования) индивидуальных рисков проекта. Данный анализ выполняется
путем оценки вероятности возникновения и воздействия рисков, а также
других характеристик. Качественный анализ рисков позволяет определить вероятность наступления рискового события; тяжесть последствий
реализации риска; ранга риска по матрице «вероятность – последствия»;
близость наступления риска по временной шкале.
В отношении рисков, квалифицированных как имеющих высокий
и средний ранг, проводится количественный анализ.
Количественный анализ рисков – это процесс численного (количественного) анализа влияния рискового события и других источников
неопределённости на проект в целом, а также определение размеров
временных и ресурсных резервов, необходимых для достижения целей
проекта. Для количественного анализа рисков необходим сбор значительного количества информации и использование специальных математических моделей и методов (например, анализ чувствительности,
анализ дерева решений, моделирование и имитация).
ГЛАВА 1. БАЗОВЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
27
Планирование реагирования на риски – это процесс разработки вариантов, выбор стратегий и согласование действий относительно проанализированных рисков проекта. Выделяют пять основных стратегий
управления рисками (рис. 1.16).
Рис. 1.16. Стратегии управления рисками
Мониторинг и управление рисками – это процесс идентификации,
систематического анализа, обнаружения и планирования реагирования
на новые риски, отслеживания ранее идентифицированных рисков, а также проверки и исполнения операций реагирования на риски и оценка
эффективности этих мероприятий. Основная цель данного процесса
состоит в обеспечении актуальной информацией о подверженности
проекта рискам.
Под проблемой в проекте понимается текущее состояние или ситуация, которая возникает в процессе осуществления проекта, затрудняет
достижение целей проекта и требует ответа – изучения и решения для
того, чтобы проект мог идти в соответствии с планом.
Проблема – это исключительные обстоятельства, возникающие под
воздействием различных факторов, например несогласованность действий
членов проектной команды или сотрудников организации, несогласованность целей проекта, конфликт и конкуренция ресурсов, срывы сроков.
В проектном управлении рассматривают две категории проблем:
1) проблемы, которые могут быть решены на уровне управления проектом; 2) проблемы, для решения которых необходима эскалация на верхние уровни управления, в том числе и внешние по отношению к проекту.
Программное обеспечение управления проектами
28
Для анализа проблем в проектном управлении могут разрабатываться
таблицы решений. Для определения приоритетности решения проблемы
может использоваться матрица приоритетов проблем, в соответствии
с которой проблемы делятся на следующие категории (рис. 1.17):
– несущественная (низкий приоритет) – имеют слабое влияние на
достижение целей проекта и могут быть проигнорированы;
– незначительная (средний приоритет) – могут оказывать некоторое
влияние на проект, не являются критическими и требуют решения в
рамках имеющихся ресурсов без изменений запланированных работ
по проекту;
– важная (средний приоритет) – оказывают некоторое влияние на
достижение целей проекта и требуют мобилизации ресурсов и срочного решения;
– особо важная (высокий приоритет) – значительно влияют на дости-
жение целей проекта и требуют привлечения необходимых ресурсов и немедленного решения.
Под изменениями в проекте понимается модификация, корректировка или добавление ранее согласованного содержания продукта (услуг),
расписания, бюджета, управленческих процессов или других аспектов
проекта. Изменения могут возникать из-за новых требований заказчика,
технических проблем, изменений внешних условий или других факторов,
которые могут повлиять на успешное завершение проекта.
Рис. 1.17. Матрица приоритетов проблем
Управление изменениями проекта включает процессы и процедуры
по оценке, утверждению, регистрации и реализации изменений, а также
отслеживания и контроля их воздействия на проект.
Ключевой документ процесса управления изменениями – запрос
на изменения, который должен содержать обоснование необходимости
изменения, суть предлагаемого решения и возможные последствия его
реализации для проекта.
ГЛАВА 1. БАЗОВЫЕ ПОНЯТИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
29
В зависимости от масштабов вносимых изменений запросы на изменения могут быть утверждены комитетом по управлению изменениями,
заказчиком, спонсором, руководителем проекта.
Процесс работы над проектом зависит от типа результата проекта.
Содержание продуктового результат проекта и подход к разработке вли
яют на количество и сроки реализации проекта. От выбранного подхода
и периодичности получения результатов проекта зависит выбор жизненного цикла проекта и этапы его выполнения.
В соответствии с ГОСТ Р ИСО 21500-2014 «Руководство по проектному менеджменту» жизненный цикл проекта представляет собой
последовательность фаз, продолжающуюся от начала до окончания проекта. Границами фаз обычно являются точки принятия решений, состав
которых может зависеть от организационного окружения проекта.
Жизненный цикл проекта состоит из этапов, которые:
1)
связывают создание ценности для бизнеса и заинтересованных сторон
от начала до конца;
2) определяют сроки реализации и подход к разработке, необходимый
для получения конечных результатов.
Тип и количество этапов в жизненном цикле проекта зависят от мно-
жества факторов, главными из которых являются сроки реализации
и подход к разработке.
Примеры фаз типового жизненного цикла проекта приведены на ри-
сунке 1.18.
Рис. 1.18. Типовой жизненный цикл проекта
На этапах жизненного цикла проекта часто проводится проверка фазо-
вых переходов, это необходимо для оценки степени достижения желаемых
результатов или выполнения критериев завершения этапа. Критерии перехода на следующую фазу могут быть связаны с критериями приемлемости
результатов, контрактными обязательствами, достижением конкретных
целевых показателей эффективности или другими показателями.
Программное обеспечение управления проектами
30
Подход к разработке – это система принципов, инструментов и техник, которые используются для создания и развития продукта, услуги
или результата в течение жизненного цикла проекта. В разных отраслях
используются разные подходы к разработке и разная терминология для
обозначения подходов к разработке. В рамках данного учебника рассмотрим три подхода к организации жизненного цикла проекта: предиктивный (прогностический), гибридный и адаптивный (рис. 1.19).
Рис. 1.19. Виды жизненных циклов проекта
1
Предиктивный (прогностический) жизненный цикл – это традиционный подход к управлению проектами 2. Ещё иногда его называют каскадным или водопадным. Предиктивный жизненный цикл предполагает, что
фазы проекта выполняются последовательно друг за другом и поставка
результата осуществляется один раз в конце проекта (рис. 1.20).
Рис. 1.20. Пример предиктивного жизненного цикла
1
Гришин Л. Agile Practice Guide: То самое обучающее руководство по гибкому мыш-
лению. – URL: https://levgrishin.ru/wp-content/uploads/2023/03/Agile- Practice- GuideRU-levgrishin-ru.pdf (дата обращения: 15.04.2024).
2
Там же.
3
Там же.
3
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]