25
По мнению Арчибальда Р.Д.
18
основная задача анализа жизненного
цикла проекта состоит в необходимости определения системы управления
жизненным циклом для конкретного проекта. Именно создание системы
управления, а не только статичная информация, является целью любого
анализа жизненного цикла проекта. При разработке любого проекта
рекомендуется:
1. Описать систему управления жизненным циклом проекта;
2. Определить фазы жизненных циклов для каждого проекта и для
каждой категории проектов, при наличии портфеля проектов;
3. Установить контрольные точки и точки принятия решений между
фазами жизненного цикла;
4. Определить промежуточные и окончательные результаты каждой
фазы;
5. Идентифицировать и соотнести друг с другом документы и
разрешения для каждой фазы.
Дезонье и Андерсон представили модель для адаптации жизненных
циклов проекта к его текущему окружению
19
. Хотя эти авторы
рассматривают только случаи разработки программного обеспечения,
данный вопрос является не менее важным и в отношении некоторых
проектов по реализации проектов в целом. Дезонье и Андерсон утверждают
следующее: «Характеристики организации, степень ее знакомства с
используемыми технологиями, вызванный конкуренцией запуск новых
проектов - это лишь некоторые из факторов окружения, варьирующиеся от
одного проекта к другому». Более того, поскольку окружение может
оказывать значительное влияние на проект, «...особое внимание необходимо
уделить выбору жизненного цикла разработки, который будет воплощен на
практике».
18
Арчибальд Рассел. Д. Управление высокотехнологичными программами и проектами, ДМК Пресс,
Компания АйТи, 2018 - с. 75
19
Desaulniers, D.H., Anderson R.J. Matching Software Development Life Cycles to the Project Environment,
Proceedings of the Project Management Institute Annual Seminars and Symposium. – Nashville, TN. Newtown
Square, PA: Project Management Institute, November 1-10, 2001 – с. 55
26
Анализ внешней среды и окружения проекта может осуществляться в
разных формах. Для структурированного представления информации может
быть использован шаблон
20
, показанный на рисунке 2. На шаблоне вся
область окружения делится на секторы — сферы, влияющие на проект.
Концентрическими окружностями разделяются группы элементов окружения
в зависимости от возможности влияния на эти элементы со стороны проекта.
Рисунок 2. Шаблон документирования обзора окружения
Факторы — это элементы окружения, которые не могут совершать
действия, но влияют на проект самим фактом своего существования.
Примерами факторов являются законы, постановления, традиции, тенденции,
экономические, физические или какие-то другие условия.
20
Арчибальд Рассел. Д. Управление высокотехнологичными программами и проектами, ДМК Пресс,
Компания АйТи, 2018 – с.63
27
При анализе жизненного цикла проекта помимо систематического
анализа внешней среды по рекомендованному шаблону необходимо
выделить группы факторов, которые:
1. оказывают влияние на изменение сроков отдельных фаз проекта
(например, задержка в принятии решения, неблагоприятные климатические
условия, задержка поставки комплектующих и оборудования и другие);
2. оказывают влияние на срыв фазы проекта и требующие
изменения технологии;
3. факторы, которые влекут удорожание стоимости фазы проекта и
проекта в целом;
4. оказывают влияние на возможность реализации всего проекта в
целом.
5. факторы, которые позволят сократить время на реализацию
отдельной фазы или проекта в целом;
6. факторы, которые позволят сократить затраты на реализацию
отдельной фазы или проекта в целом.
Учет подобного рода факторов, понимание их природы и силы
воздействия позволит сформировать перечень мероприятий, которые
позволят нивелировать или уменьшить неблагоприятное влияние и
воспользоваться факторами, которые ускоряют реализацию проекта.
Работа с выявленными факторами окружения предусматривает учет
влияния факторов при планировании и обосновании проекта, а также
мониторинг изменения ключевых факторов и отражение изменений в планах
проекта.
Пример специальных мероприятий, направленных на обеспечение
взаимосвязи проекта с его окружением, приведен в таблице 2.
28
Таблица 2
Взаимодействие проекта с окружением
Задачи управления
проектами
Мероприятия,
направленные на
действующих лиц
Мероприятия,
направленные на
ключевые факторы
1. Определение проекта
Вовлечь действующих
лиц в процесс
определения; если
можно, использовать их
идеи; объяснить им суть
проекта; определить
проблемы и негативные
реакции
Включить первостепенные
факторы в допущения
планирования,
идентифицировать
налагаемые ими
ограничения, которые
влияют на определение
проекта
2. Организация и
формирование команды
Установить формальные,
рабочие и
неформальные
отношения с
действующими лицами;
рассматривать их как
членов команды
проекта, при
необходимости
приглашать на
совещания по проекту
Включить влияние
факторов в
организационную
структуру; сообщить
членам команды все
ключевые факторы и
прояснить их влияние на
успех проекта
3. Создание плана,
расписания и бюджета
По возможности
привлечь действующих
лиц к подготовке
планов, расписаний и
бюджетов;
удостовериться, что
планы отражают
реальность,
определяемую
ключевыми
действующими лицами
Внести информацию,
имеющую отношение к
ключевым факторам, в
планы, бюджеты и
расписания
4. Авторизация работ и
начало исполнения
Постоянно
информировать
действующих лиц о ходе
выполнения проекта,
особенно когда
операции напрямую
влияют на них
По возможности вести
мониторинг факторов во
избежание возникновения
прямых конфликтов и
проблем
5. Контроль исполнения
работ, расписания и
бюджета
Постоянно
информировать
действующих лиц о ходе
выполнения проекта,
особенно когда
операции напрямую
влияют на них
По возможности вести
мониторинг факторов во
избежание возникновения
прямых конфликтов и
проблем
29
6.Оценка хода работ и
руководство проектом
По возможности
включить действующих
лиц в процесс оценки;
заранее предоставлять
им информацию об
основных изменениях
Периодически обновлять
данные по каждому
ключевому фактору и
включать их в процесс
оценки хода работ
7. Закрытие проекта
Привлечь действующих
лиц к планированию и
операциям закрытия;
продолжать
информирование
Продолжать следить за
факторами и вносить
изменения в планы
закрытия
Кроме того, для успешной реализации проекта необходимо разработать
процедуры управления и организационные мероприятия, которые обеспечат
переход от одной фазы к другой.
Однако, простое выделение процессов каждой фазы и жизненного
цикла, зачастую, неточно указывает на порядок их выполнения во времени.
Для этих целей используются модели.
1.3. Методы и модели управления проектами
Традиционное управления проектом включает в себя упорядоченные,
тщательно спланированные и управляемые методы. При таком подходе
этапы жизненного цикла проекта выражены достаточно явно. Задачи
выполняются одна за другой в определенном порядке, при этом требуется
уделить значительное количество времени на планирование полного
процесса реализации проекта. Основная предпосылка традиционных методов
состоит в том, что события, влияющие на проект, легко предсказуемы, а
инструменты и действия - легко усваиваемы. Важной особенностью
традиционных моделей является то, что при завершении одного этапа
предполагается, что возврат к нему не будет осуществлен.
Примером такой традиционной модели является модель водопада
(waterfall model). Суть ее заключается в том, что процесс реализации проекта
выглядит как поток, последовательно проходящий следующие фазы:
1. Определение требований
2. Проектирование
30
3. Конструирование («реализация» или «кодирование»)
4. Интеграция
5. Тестирование и отладка («верификация»)
6. Инсталляция
7. Поддержка
Видно, что, хотя данная модель была разработана для программных
проектов фазы применимы и для других типов проектов.
Переход от стадии к стадии происходит строго последовательно и
модель подразумевает, что переход от одной фазы разработки к другой
происходит только после полного и успешного завершения предыдущей
фазы, а переходов назад либо вперёд или перекрытия фаз не происходит.
С одной стороны, такой подход имеет ряд преимуществ: на первом
этапе проводится анализ всех необходимых мероприятий. К недостаткам
данных моделей относится их относительная негибкость: на практике,
практически не представляется возможным учесть все факторы,
оказывающие влияние, сформулировать все требования. Наиболее
существенным недостатком такого подхода являются накопление возможных
на ранних этапах ошибок к моменту окончания проекта и, как следствие,
возрастание риска провала проекта, увеличение стоимости проекта.
Для устранения этого недостатка было разработано значительное
количество итеративных моделей. Начиная с 2009 года Институтом
Проектного Менеджмента (PMI) предлагается, как стандарт, гибридный
вариант методологии управления проектами, сочетающий в себе плюсы от
методики водопада, так и достижения итеративных методологов.
Итеративный подход предполагает выполнение работ параллельно с
непрерывным анализом полученных результатов и корректировкой
предыдущих этапов работы. Проект при этом подходе в каждой фазе
развития проходит повторяющийся цикл: планирование - реализация -
проверка - оценка (plan-do-check-act cycle).
Преимущества итеративного подхода заключаются в следующем:
31
- снижение воздействия серьезных рисков на ранних стадиях
проекта, что ведет к минимизации затрат на их устранение;
- снижение вероятности аккумуляции ошибок
- организация эффективной обратной связи;
- учет возможных изменений внешней среды и соответствующая
корректировка проекта;
- раннее обнаружение конфликтов между требованиями, моделями
и реализацией проекта;
- более равномерная загрузка участников проекта;
В управлении проектами по разработке программного обеспечения
используется зачастую спиральная модель жизненного цикла модель Боэма.
Принципиальное отличие данной разновидности итеративной модели
заключается в том, что на каждом витке спирали рассматривается
зависимость эффективности проекта от его стоимости с течением времени. В
ряде случаев, например, при моделировании жизненного цикла выпуска
нового высокотехнологичного проекта, практика оценки эффективности на
каждой стадии является целесообразной.
Моделирование жизненного цикла проекта инкрементным методом
предполагает разбиение большого объема проектно-конструкторских работ
на последовательность более малых составляющих частей.
В Приложении 3 показаны основные модели и возможности их
применения для разных типов моделей.
Свод знаний по управлению проектами (PMBOK)
21
вводит такое
понятие как «успешная практика». Под этим термином понимается общее
мнение относительно того, что применение определенных процессов
управления проектом в соответствующих внешних условиях повышает
шансы на успех. Также, для этих процессов определена последовательность
их выполнения, необходимая входная информация, инструменты, с помощью
21
Свод знаний по управлению проектами (PMBOK) / Пер.с англ. – М.: ПМСОФТ, 2014 – с. 48
32
которых реализуется каждый процесс, методы реализации, а также
результаты каждого процесса. Эти процессы относятся к управлению:
- содержанием проекта;
- сроками проекта;
- стоимостью проекта;
- качеством проекта;
- человеческими ресурсами проекта;
- коммуникациями проекта;
- рисками проекта;
- поставками проекта.
Бурков В. и Новиков Д. показали, что успешная реализация любого
проекта требует последовательного решения следующих общих задач
22
:
- определение и анализ целей проекта;
- построение, оценка и выбор альтернативных решений по
реализации проекта (вариантов проекта);
- формирование структуры проекта, выбор состава исполнителей,
ресурсов, сроков и стоимости работ;
- управление взаимодействием с внешней средой;
- управление исполнителями (персоналом);
- регулирование хода работ (оперативное управление, внесение
корректив).
Видно, что решение этих задач соответствует решению задач
управления проектами (Таблица 3).
Таблица 3
Этапы управления проектами и задачи данных этапов
Этапы управления проектами
Задачи
Целеполагание
прогнозирование и оценка результатов
Планирование
планирование
Управление ресурсами
распределение ресурсов
Стимулирование и контроль
стимулирование исполнителей
Оперативное управление
оперативное управление
22
Бурков В.Н., Новиков Д.А. Как управлять проектами. – М.: Синтег, 2016. – с. 87
33
Проект в целом и каждый из исполнителей в отдельности
характеризуются следующими показателями:
- объем работ;
- качество работ;
- необходимые финансовые, материальные и др. ресурсы;
- состав участников (кадры);
- риск;
- сроки выполнения.
С точки зрения управления проектами структура проекта включает
следующие блоки:
1. Структура работ (WBS – Works Breakdown Structure). Под
структурой декомпозиции работ понимают иерархическую структуру,
позволяющую разделить проект на отдельно или совместно управляемые
части – пакеты работ. Каждый нижестоящий уровень структуры
представляет собой детализацию элемента более высокого уровня. Каждый
пакет работ характеризуется объективным и измеримым результатом, а также
ответственным за достижение этого результата. Пакеты работ могут
соответствовать подцелям проекта (структура декомпозиции целей
называется деревом целей). С помощью структуры декомпозиции работ
описывается содержание проекта.
2. Организационная структура (OBS – Organization Breakdown
Structure), - отражает иерархическую взаимную подчиненность участников
проекта (руководителя проекта в целом, руководителей подпроектов / работ,
исполнителей). Для проектной деятельности характерны матричные
организационные структуры, в рамках которых каждый исполнитель
одновременно подчинен нескольким руководителям – например, своему
функциональному руководителю и руководителю проекта;
3. Структура ресурсов (RBS – Resources Breakdown Structure).
Отметим, что декомпозиция осуществляется как по видам ресурсов
(условиям осуществления деятельности: мотивационным, кадровым,
34
материально-техническим, научно-методическим, финансовым,
организационным, нормативно-правовым, информационным), так и по
«количествам» ресурсов того или иного вида.
4. Сетевой график - отражает логику и технологию выполнения
работ. Отметим, что обычно используются сетевые графики нескольких
уровней – от детального графика работ, до агрегированного графика
основных подпроектов. При этом определенному уровню детализации
сетевого графика соответствуют определенные уровни структуры работ,
организационной структуры и структуры ресурсов.
Методики сетевого планирования, разработанные впервые в конце 50-х
годов в США и получившие название Метода Критического Пути - МКП
(или CPM - Critical Path Method) широко используются при анализе
жизненного цикла проекта. По сути, сетевое планирование является
реализацией модели жизненного цикла или программы - содержания и плана
действий
23
– это конкретный план действий по реализации модели в
определенных условиях и в установленные (определенные) сроки.
Построение программы начинается с операции «определения основных
вех»
24
. Определение вех составляет начальную, наиболее обобщенную часть
программы, которая потом развертывается в укрупненный и, наконец, в
детальный план.
При определении вех используется информация о ключевых точках,
под которыми понимаются состояния, через которые будет проходить
процесс реализации проекта. Вехи отмечают существенные, определяющие
дальнейший ход развития процесса точки перехода и позволяют решать
проблемы контроля реализации проекта, составляя набор естественных
контрольных точек. Они используются в качестве дискретной шкалы,
которая имеет всего две оценки – «выполнено» или «не выполнено».
23
Советов Б.Я., Яковлев С.А. Моделирование систем. – М.: Высшая школа, 1998. –с. 158
24
Лысаков А.В., Новиков Д.А. Договорные отношения в управлении проектами. – М.: ИПУ РАН, 2017 – с.
77