CC BY
23
УДК 303.732.4
05.00.00 Технические науки
ПРОБЛЕМАТИКА УСПЕШНОСТИ ПРОЕКТОВ В СФЕРЕ СИСТЕМНОЙ ИНТЕГРАЦИИ
Карпенко Пётр Игоревич
магистрант факультета Прикладной информатики, SPIN-код: 7968-5986
Комяков Максим Юрьевич
магистрант факультета Прикладной информатики, SPIN-код: 1203-4928
Федеральное государственное бюджетное образовательное учреждение высшего образования «Кубанский государственный аграрный университет имени И. Т. Трубилина», Краснодар, Россия
В статье рассмотрены отличительные особенности ведения проектной деятельности как в сфере информационных технологий в целом, так и в области системной интеграции в частности. Произведен анализ успешности проектов в рамках общемировой практики ведения проектной деятельности в сфере информационных технологий, рассмотрены критерии успешности проектов, а также их эволюцию с течением времени. Показаны основные проблемы и риски, касающиеся реализации проектов. Произведена идентификация причин, влекущих за собой негативные последствия для проектной деятельности. Рассмотрена взаимосвязь выявленных проблем с основными фазами жизненного цикла проекта, а также с фундаментальными характеристиками проектной деятельности. Отражена роль менеджера проектов в ведении проектной деятельности и значимость его вклада в успешную реализацию проектов. Выработан комплекс мер, направленных на минимизацию выявленных рисков и повышение успешности ведения проектной деятельности в сфере информационных технологий и области системной интеграции
Ключевые слова: ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ, СИСТЕМНАЯ ИНТЕГРАЦИЯ, ИНФОРМАЦИОННАЯ СИСТЕМА, БИЗНЕС-ПРОЦЕСС, ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ, УПРАВЛЕНИЕ ПРОЕКТАМИ
Рок 10.21515/1990-4665-133-076
UDC 303.732.4 Technical sciences
THE PROJECTS SUCCESS ISSUES IN SYSTEM INTEGRATION
Karpenko Petr Igorevich
Master of Applied information faculty
SPIN-code: 7968-5986
Komyakov Maxim Yurevich Master of Applied information faculty SPIN-code: 1203-4928
Federal State Educational Institution of Higher Education "Kuban State Agrarian University named by I.T. Trubilin", Krasnodar, Russia
The article explores the distinctive features of project management in the field of information technologies in general and in system integration in particular. We have analyzed and explored the success of project management cases in global practice of project management in information technologies, explored the criteria of success in projects and its evolution throughout the history. The article also investigates the main problems and risks in project realization and identifies the factors, causing the negative effect on project management. We have explored the interconnections between the identified problems and the lifecycle of the project and the fundamental features of the project management. We have also paid attention to the role of the project manager and the importance of his contribution to the project. We have worked out a set of measures entitled to minimize the identified risks and to increase the success of project management in information technologies and system integration
Keywords: INFORMATION TECHNOLOGY, SYSTEM INTEGRATION, INFORMATION SYSTEM, BUSINESS PROCESS, PROJECT ACTIVITY, PROJECT MANAGEMENT
Введение
Системная интеграция является одним из ключевых видов деятельности, относящихся к сфере информационных технологий. Главная цель системной интеграция - разработка комплексных решений по автоматизации технологических и бизнес-процессов предприятия, являющегося заказчиком компании-интегратора. Конечная цель компании-интегратора - извлечение прибыли из реализации решений, соответствующих нуждам и потребностям заказчика, для обеспечения максимально эффективного управления технологическим процессом, производством, так и организацией в целом.
В системной интеграции широко используется проектное управление, т. к. данный подход соответствует требованиям, накладываемым данным видом деятельности - он несет в себе ограничения по времени и ресурсам, выделяемым на реализацию каждого из проектов. Без подобных ограничений успешное ведение коммерческой деятельности практически невозможно.
Проекты в области системной интеграции обладают высокой степенью неопределенности - это связано с особенностями предметной области, включающей в себя большое количество различных дисциплин и направлений, которые в подавляющем большинстве случаев одновременно задействованы в рамках одного проекта. Стоит отметить, что проекты в области системной интеграции зачастую реализуются в рамках ландшафта, уже имеющегося у заказчика, что в конечном счете существенно усложняет их реализацию, т. к. необходимо обеспечить бесшовную интеграцию с имеющимися решениями либо обеспечить плавный переход на внедряемые системы, что в свою очередь требует высокой квалификации специалистов, являющихся частью проектной команды. По наблюдениям авторов статьи, высокая степень неопределенности приводит к широкому спектру проблем, связанных с ведением проектной деятельности в данной области, основной из
которых является большая доля проблемных или проваленных проектов от общего количества проектов.
В рамках данной статьи авторы рассматривают:
1. Критерии успешности проектов в сфере информационных технологий и их эволюцию с течением времени.
2. Актуальность проблемы, касающейся малой доли успешных проектов в области информационных технологий от общего числа проектов, реализованных в рамках данной сферы.
3. Идентификация основных причин возникновения проблем, связанных с неуспешным ведением проектной деятельности.
4. Выработка рекомендаций по повышению успешности ведения проектной деятельности.
Данная статья опирается на материалы руководства к своду знаний по управлению проектами Project Management Body of Knowledge (далее PMBOK), всемирной некоммерческой профессиональной организацией по управлению проектами Project Management Institute (далее PMI), шестая редакция которого была выпущена в сентябре 2017 года.
Материалы и методы исследований
В ходе анализа отчетов «CHAOS Report» с 2011 по 2015 годы [2][5], которые содержат консолидированные данные по проектам в области информационных технологий, формируемым компанией Standish Group на ежегодной основе (с 1994 года и по текущий момент), была подготовлена консолидированный график, содержащий информацию с 2011 по 2015 годы, который показан на Рисунке 1 ниже:
2011 2012 2013 2014 2015
• Успешные Проблемные • Проваленные
Рисунок 1 Результаты проектов в области информационных технологий с 2011 по 2015 годы.
Также были рассчитаны средние значения показателей успешности проектов, которые показаны Таблице 1, представленной ниже:
Категория проекта 2011 2012 2013 2014 2015 Среднее значение
Успешные 29% 27% 31% 28% 29% 29%
Проблемные 49% 56% 50% 55% 52% 52%
Проваленные 22% 17% 19% 17% 19% 19%
Таблица 1 Средние значения показателей успешности проектов в области информационных технологий с 2011 по 2015 годы.
Принимая во внимания среднее значение показателей успешности проектов за 5 лет можно сделать вывод о том, что:
1. В среднем всего лишь 29% проектов являются успешными. К данной категории относятся те проекты, для которых одновременно выполняются три условия: проект был выполнен в срок, без превышения бюджета, результат проекта удовлетворил заказчика. Для каждого из проектов, включенных в рамки исследования, также рассматриваются три следующих показателя:
результат реализации целевого функционала (измеряется в процентах от объема изначально запланированных к реализации возможностей и функций), ценность проекта для заказчика (от очень низкой до очень высокой) и уровень соответствия стратегическим целям заказчика (от отдаленного до высокого уровня соответствия). Стоит отметить, что до 2015 года компания Standish Group использовала несколько другой подход - в качестве критериев успешности проекта использовалось так называемое «Тройственное Ограничение» или «Железный Треугольник», которое было введено в третьей редакции PMBOK. «Тройственное Ограничение» представляет из себя одновременное выполнение трех следующих условий: соблюдение сроков реализации проекта, нахождение в рамках заранее определенного бюджета и реализация всех изначально запланированных требований (возможности, функционал и т.д.). Таким образом произошло смещение акцентов от полноты реализации объема работ (имплементация всех запланированных возможностей и функционала) к использованию удовлетворенности заказчика в качестве одного из ключевых критериев оценки [3][4]. Данное изменение было вызвано тем, что в использовавшейся ранее методике с каждым годом все более явно вырисовывался недостаток, заключающийся в том, что формально успешные проекты, полностью соответствующие «Тройственному Ограничению», в конечном счете не несли в себе для заказчика ценности, ожидавшейся изначально, что в свою очередь приводило к неудовлетворенности спонсоров проекта, а зачастую и к тому, что заказчик переставал использовать продукт, полученный в
результате реализации проекта в течение нескольких лет после формально успешной его реализации. Одновременно с изменением перечня критериев успешности проектов представители компании Standish Group провели актуализацию данных отчетов с 2011 по 2014 годы. В Таблице 1, представленной выше, содержится обновленная информация, которая была актуализирована после внесения изменений в систему оценки. Также стоит обратить внимание на тот факт, что изменение системы оценки привело к снижению доли успешных проектов в среднем на 7%.
2. В среднем 52% проектов являются проблемными (скомпрометированными). К данной категории относятся те проекты, которые были завершены, но при этом произошло нарушение любого из трех критериев успешности, обозначенных выше.
3. В среднем 19% проектов были провалены. К данной категории относятся те проекты, которые по тем или иным причинам были отменены в ходе реализации, либо результат работы по которым не был принят заказчиком.
Таким образом, из общего числа проектов, которые относятся к сфере информационных технологий, лишь около 29% можно назвать полностью успешными. Стоить отметить, что в рамках проводимого исследования компания Standish Group рассматривает более 50 000 проектов, что является залогом высокой степени репрезентативности полученной информации.
Количество неуспешных проектов, содержащиеся в отчетах Standish Group, в целом превышает аналогичные показатели по другим отраслям [7][8]. К сожалению, прямое сравнение отчетов между собой невозможно
ввиду существующей разницы в подходах к проведению оценки (в разных исследованиях используются неодинаковый набор критериев).
Предлагаем рассмотреть основные проблемы, которые были выявлены в рамках исследований, проводимых Standish Group [5]:
1. Повторная инициация проекта, вызванная необходимостью его перезапуска. На каждые 100 проектов приходилось как минимум 94 проекта, которые бы перезапускались один или более раз.
2. Выход за рамки изначально определенного бюджета. Около трети проектов, относящихся к категориям «Проблемный» и «Проваленный», превысили первоначальный бюджет на 150%-200%. В среднем превышение бюджета составило около 189% от начальных значений.
3. Выход за рамки изначально определенных сроков. Длительность более трети проектов, относящихся к категориям «Проблемный» и «Проваленный», составила от 200% до 300% от первоначально запланированной продолжительности. Среднее превышение продолжительности проекта составило 222% от первоначально запланированных значений данного параметра.
4. Неполное соответствие результата проекта изначально запланированным требованиям. В более чем четверти проектов, относящихся к категории «Проблемных», было реализована лишь малая часть (от 25% до 49%) от первоначально запланированного функционала. В данной категории проектов в среднем было реализовано около 61% от первоначально запланированного объема требований (возможности, функционал и т.д.).
Для поиска способов, которые помогут минимизировать вероятность возникновения обозначенных выше проблем, необходимо провести анализ
причин возникновения наиболее частых проблем и сопоставить их с жизненным циклом проекта с целью выявления фаз, которые оказывают максимальное влияние на успешность реализации проекта в целом, а также обратиться к определению термина «проект» и рассмотреть его фундаментальные свойства в разрезе обозначенных проблем. Стоит отметить, что за успешность реализации проекта в первую очередь несет ответственность менеджер проектов.
со
Е
о ^
а Мониторинг н Закрытие
Рисунок 2 Жизненный цикл проекта.
На Рисунке 2, представленном выше, показаны фазы жизненного цикла проекта. Стоит отметить, что происходит последовательный переход между фазами проекта, т.е. фаза Планирования не может быть начата до завершения фазы Инициации проекта. Фазы Планирования, Выполнения и Мониторинга являются циклически повторяющимися процессами, по сути они представляют собой вариацию Цикла Деминга1. Выделяют «ранние» и «поздние» стадии фазы Планирования: при «раннем» планировании происходит формирование планов, а при «позднем» - их уточнение.
Необходимо более подробно рассмотреть результаты каждой из фаз жизненного цикла проекта, которые тем или иным образом влияют на обозначенные ранее проблемы [12]:
1 Цикл Деминга, также известный как РБСЛ (англ. «Р1ап-Эо-СЬеск-Ас1;» - планирование-действие-проверка-корректировка) - циклически повторяющийся процесс принятия решения, используемый в управлении качеством.
1. Инициация. В результате данного этапа формируются следующие документы:
1.1. Реестр заинтересованных сторон - реестр, включающий в себя лиц, группы лиц или организации, которые могут влиять, на которые могут влиять или которые могут воспринимать себя подвергнутыми влиянию решения, операции или результата проекта. Данный реестр будет изменяться и дополняться по ходу реализации проекта.
1.2. Устав проекта - является одним из основных результатов данной фазы. Устав проекта не должен изменяться в ходе проекта ни при каких условиях. По сути, устав является «скорлупой» проекта, за рамки которой нельзя выходить. Внесение изменений в устав проекта равносильно остановке текущего проекта и запуску нового. Устав проекта включает в себя цели (бизнес-цели проекта), ограничения (сроки реализации, бюджет, объем работ - «Тройственное Ограничение»), заинтересованные стороны (ключевые), результаты поставки (главные), ключевые показатели эффективности (ключевые), риски (основные).
2. Планирование. В рамках данного этапа происходит работа с внутренним содержимым «скорлупы» проекта:
2.1.Матрица требований - документ, содержащий перечень требований к продукту, являющемуся результатом проекта (чаще всего используется табличная форма записи).
2.2.Концепция проекта - это детальное целостное описание работ в удобной для команды форме, обычно готовится после балансировки требований и является уточнением содержания устава проекта. Содержит в себе уточненные сведения о том, что входит и не входит в проект, ограничения, допущения.
2.3.Иерархическая структура работ - представляет собой декомпозицию содержания проекта и показывают иерархию работ, необходимых для его реализации. При этом иерархическая структура работ не обязательно отражает последовательность работ.
2.4. Последовательность работ - представляет из себя сетевую диаграмму, которая строится на основе иерархической структуры работ, подготовленной ранее.
2.5. Необходимые ресурсы - определение количества ресурсов, необходимого для каждого из видов работ, зафиксированных на этапе формирования последовательности работ.
2.6. Продолжительность работ - оценка продолжительности работ является одним из сложнейших элементов планирования в рамках реализации проекта. К сожалению, точно планировать продолжительность работ невозможно, всегда имеется определенная погрешность. При оценке продолжительности можно использовать дополнительные методы планирования и уточнения полученных ранее оценок.
2.7. Расписание проекта - формируется на основании последовательности работ, данных о необходимых ресурсах и оценки продолжительности работ, подготовленных ранее. При создании расписания проекта также учитываются следующие данные: дата начала проекта, нерабочее время (рабочие часы, отпуска сотрудников и т. д.), дополнительные правила (выходные дни, праздничные дни и т.д.). После формирования расписания проекта обычно определяется его критический путь2, который позволяет рассчитать минимальную продолжительность проекта, оценить возможности расписания проекта и выделить самые
2 Критический путь - это последовательность работ, образующая самый длинный путь внутри сетевой диаграммы, который в свою очередь служит для определения кратчайшего из возможных сроков завершения проекта.
рискованные участи, т.е. какие работы могут быть смещены и насколько, кадры какой квалификации необходимо назначать на те или иные работы и т. д. Расписание проекта подлежит оптимизации: как сразу же после его формирования, так и после возникновения любых, сколько-нибудь существенных, проблем в рамках реализации проекта.
2.8.Бюджет - после подготовки расписания проекта происходит определение плановой стоимости проекта.
2.9. Другие планы, к которым относятся:
2.9.1. Реестр рисков - документ, содержащий перечень рисков, их качественный и количественный анализ, а также планы реагирования на них.
3. Выполнение - реализация работ в рамках проекта.
4. Мониторинг - контроль текущего статуса реализации проекта.
5. Закрытие - сохранение информации по проекту для дальнейшего использования и наполнение базы знаний: примеры успешной оценки трудозатрат (продолжительность работ и необходимые ресурсы), удачные планы, информацию по рискам, разработанные шаблоны документов, предзаполненные документы и др. К сожалению, в рамках данной фазы зачастую происходит формальное закрытие проекта, без наполнения базы знаний - это приводит к тому, что успешный опыт, полученный в рамках текущего проекта, не применяется в будущих проектах, что является весьма серьезным упущением.
Таким образом, содержимое проекта можно разделить на две составляющих:
1. «Скорлупа» проекта - остается неизменной в ходе всего проекта. Изменение скорлупы приводит к перезапуску проекта, что по сути
равносильно его провалу. Устав проекта является скорлупой проекта (см. п. 1.2 «Устав проекта» выше).
2. Внутреннее содержимое «скорлупы» проекта - гибкие составляющие проекта, которые безболезненно изменяются (перерабатываются, уточняются, дополняются) в ходе проекта. Допустимы любые изменения, которые не противоречат уставу проекта, т.е. не противоречат зафиксированным в нем ограничениям. К внутреннему содержимому «скорлупы» проекта относятся все составляющие, полученные в результате реализации фазы Планирования (см. п. 2 «Планирование» выше).
Перед тем, как перейти к выводам, давайте рассмотрим термин «проект» и фундаментальные характеристики проектной деятельности, которые ее определяют.
Проект - это временное предприятие, направленное на создание уникального продукта, услуги или результатов [1].
Фундаментальными характеристиками проектной деятельности являются:
1. Высокая степень неопределенности - связана с большим количеством неизвестных и уникальностью продукта, являющимся результатом реализации проекта. Для сферы информационных технологий в целом и для области системной интеграции в частности, данный показатель будет существенно выше, чем для других отраслей - это связано с особенностями предметной области, которая включает в себя огромное количество различных дисциплин и направлений, которые в подавляющем большинстве случаев одновременно задействованы в рамках одного проекта. Также немаловажным является тот факт, что проекты в области
системной интеграции чаще всего реализуются в ландшафтах, уже существующих у заказчика , что в конечном счете существенно усложняет их реализацию, т.к. необходимо обеспечить бесшовную интеграцию с имеющимися решениями либо обеспечить плавный переход на внедряемые системы, что в свою очередь невозможно без проведения детальных обследований.
2. Конечность - ограничения по времени и ресурсам, выделенным на реализацию проекта.
Итак, какие же выводы мы можем сделать на основании материалов, приведенных выше? Авторы статьи считают, что:
1. Основная проблема успешного ведения проектной деятельности заключается в том, что все основные ограничения, часть из которых впоследствии используются для оценки проекта (такие как «Тройственное Ограничение» и другие), определяются на стадии формирования устава проекта, в рамках фазы Инициации проекта (см. п. 1 «Инициация» выше), а детальное планирование осуществляется только в рамках фазы Планирования (см. п. 2 «Планирование» выше). В связи с тем, что фаза Инициации проекта предшествует фазе Планирования, результаты детального планирования, которые бы пригодились при формировании устава проекта, на практике появляются у менеджера проектов только после подготовки и подписания устава. Стоит также учитывать, что в большинстве случаев проектная команда формируется и поступает в распоряжение менеджера проектов только после того, как подготовлен устав проекта.
2. Чем выше степень неопределенности в проекте, тем выше вероятность того, что в уставе будут зафиксированы ограничения,
которые впоследствии окажутся очень далекими от реальности. Данная причина объясняет большое количества проблемных и неуспешных проектов в области информационных технологий. Также степень неопределенности напрямую связана с размерами проекта - чем крупнее проект, тем выше степень неопределенности, а соответственно и риски, сопутствующие реализации проекта.
3. Ситуация с некорректными ограничениями, заложенными в устав проекта, также может усугубляться еще и тем, что в ряде организаций, в которых процессы проектного управления не прошли полный путь становления и закрепления, менеджера проектов привлекают к проекту уже после завершения фазы Инициации проекта, т. е. когда устав проекта уже подготовлен и подписан, что является нарушением рекомендаций, зафиксированных в РМВОК. Такая практика является недопустимой, т.к. менеджер проектов - лицо несущее ответственность за успех или провал вверенного ему проекта.
Результаты
Для решения проблем, обозначенных в данной статье, следует использовать следующие подходы, которые должны быть применены менеджером проектов:
1. Вынести первую итерацию фазы Планирования в отдельный проект, который будет предшествовать реализации основного проекта. После завершения отдельного проекта, включающего в себя первую итерацию фазы Планирования, у менеджера проектов будет иметься уточненная информация по будущему проекту, которая должна быть использована при подготовке устава
основного проекта (в первую очередь в части имеющихся ограничений). К сожалению, данный подход может быть использован далеко не всегда, т. к. его реализация связана с дополнительными финансовыми и временными затратами.
2. В случае, если у менеджера проектов есть возможность привлечения членов проектной команды еще до утверждения и подписания устава проекта, т. е. до непосредственной инициации самого проекта, то имеет смысл провести первую итерацию фазы Планирования перед фазой Инициации, что позволит включить в устав проекта уточненную информацию по реализуемому проекту (в первую очередь в части имеющихся ограничений). Данный подход также связан с дополнительными финансовыми и временными затратами, поэтому он не является универсальным.
3. Использовать методы уточнения сроков реализации и бюджета проекта при формировании устава проекта. Данный подход может быть использован в любых ситуациях. Желательно комбинировать его с использованием базы знаний (см. п. 4 ниже). Перечень методов приведен ниже:
1. Экспертные суждения (сроки и бюджет).
2. Оценка по аналогу (сроки и бюджет).
3. Параметрическая оценка (сроки и бюджет).
4. Оценка по трем точкам (сроки и бюджет).
5. Техники группового принятия решений (сроки и бюджет).
6. Анализ рисков (сроки и бюджет).
7. «Снизу-вверх» (бюджет).
8. «Сверху-вниз» (бюджет).
9. «Цена качества» (бюджет).
10. Анализ цен поставщиков (бюджет).
4. Использовать базу знаний (корпоративную и/или свою собственную), которая содержит информацию по аналогичным проектам. Данная рекомендация является наиболее универсальной из представленных выше и может быть применена в любой ситуации. Информация, содержащаяся в базе знаний, представляет собой очень большую ценность как для менеджера проектов, так и для проектной организации, т. к. позволяет существенно повысить точность оценки сроков реализации проекта, особенно на его ранних этапах.
5. Для повышения степени удовлетворенности заказчика и для более четкого понимания его бизнес-целей, которые необходимо достичь в рамках осуществления проектной деятельности, требуется обеспечить более тесное взаимодействие менеджера проектов и проектной команды с ключевыми заинтересованными сторонами на самых ранних этапах реализации проекта, а также организовывать привлечение менеджера проектов либо перед началом фазы Инициации проекта либо в самом ее начале.
Заключение
Высокая степень неопределенности, которая является фундаментальной характеристикой проектной деятельности в целом, а также весьма характерна для всей области информационных технологий и системной интеграции в частности, наносит серьезный отпечаток на успешность реализации проектов. Большое количество неизвестных, имеющихся на начальных стадиях проекта, может привести к срыву проекта, что весьма негативным образом сказывается на всех субъектах, вовлеченных в проектную деятельность (как на заказчике, так и на исполнителе проекта). Для успешного ведения
проектной деятельности, особенно на ранних ее этапах, исполнитель проекта должен сосредотачивать свои усилия на минимизации количества неизвестных и организовывать максимально плотное взаимодействие с заказчиком, что будет являться залогом успешной реализации проекта.
Для повышения успешности ведения проектной деятельности в области информационных технологий необходимо использовать комплексный подход, включающий в себя один или несколько методов описываемых авторами статьи.
Литература
1. Project Management Institute. A guide to the project management body of knowledge (PMBOK guide), Sixth edition / Project Management Institute. - Newtown Square, PA, USA: Project Management Institute, 2017. - 756 p. - ISBN: 9781628251845.
2. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch [Электронный ресурс]. - Электрон. текстовые дан. - InfoQ. - Режим доступа: https://www.infoq.com/articles/standish-chaos-2015 (Дата обращения: 01.11.2017).
3. Success Redefined [Электронный ресурс]. - Электрон. текстовые дан. - Standish Group. - Режим доступа: http://blog.standishgroup.com/post/23 (Дата обращения: 01.11.2017).
4. CHAOS Manifesto Review [Электронный ресурс]. - Электрон. текстовые дан. -Standish Group. - Режим доступа: http://blog.standishgroup.com/post/14 (Дата обращения: 01.11.2017).
5. The Standish Group - CHAOS Report [Электронный ресурс]. - Электрон. текстовые дан. - Project Smart. - Режим доступа: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf (Дата обращения: 01.11.2017).
6. Big Bang Boom [Электронный ресурс]. - Электрон. текстовые дан. - Standish Group. - Режим доступа: https://www.standishgroup.com/sample_research_files/BigBangBoom.pdf (Дата обращения: 01.11.2017).
7. PMI's Pulse of the Profession [Электронный ресурс]. - Электрон. текстовые дан. -Project Management Institute. - Режим доступа: https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf (Дата обращения: 01.11.2017).
8. KPMG's Project Management Survey 2017 [Электронный ресурс]. - Электрон. текстовые дан. - Project Smart. - Режим доступа: https://assets.kpmg.com/content/dam/kpmg/nz/pdf/July/projectmanagementsurvey-kpmg-nz.pdf (Дата обращения: 01.11.2017).
9. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling 11th Edition / Harold Kerzner. - Hoboken, NJ, USA: John Wiley & Sons, 2013. -1296 p. - ISBN: 9781118022276.
10. Verzuh E. The Fast Forward MBA in Project Management / Eric Verzuh. - Hoboken, NJ, USA: John Wiley & Sons, 2012. - 544 p. - ISBN: 9781118073773.
11. Berkun S. Making Things Happen: Mastering Project Management (Theory in Practice), Revised Edition / Scott Berkun. - Sebastopol, CA, USA:O'Reilly Media, 2008. - 544 p. - ISBN: 9780596517717.
12. Селиховкин И. Управление ИТ-проектом. Эффективная система «с нуля» в любой организации. [Электронный ресурс] / Иван Селиховкин. - Электрон. текстовые дан.
- PMlead. - Режим доступа: http://pmlead.ru/books.html (Дата обращения: 01.11.2017).
References
1. Project Management Institute. A guide to the project management body of knowledge (PMBOK guide), Sixth edition / Project Management Institute. - Newtown Square, PA, USA: Project Management Institute, 2017. - 756 p. - ISBN: 9781628251845.
2. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch [Jelektronnyj resurs].
- Jelektron. tekstovye dan. - InfoQ. - Rezhim dostupa: https://www.infoq.com/articles/standish-chaos-2015 (Data obrashhenija: 01.11.2017).
3. Success Redefined [Jelektronnyj resurs]. - Jelektron. tekstovye dan. - Standish Group.
- Rezhim dostupa: http://blog.standishgroup.com/post/23 (Data obrashhenija: 01.11.2017).
4. CHAOS Manifesto Review [Jelektronnyj resurs]. - Jelektron. tekstovye dan. - Standish Group. - Rezhim dostupa: http://blog.standishgroup.com/post/14 (Data obrashhenija: 01.11.2017).
5. The Standish Group - CHAOS Report [Jelektronnyj resurs]. - Jelektron. tekstovye dan.
- Project Smart. - Rezhim dostupa: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf (Data obrashhenija: 01.11.2017).
6. Big Bang Boom [Jelektronnyj resurs]. - Jelektron. tekstovye dan. - Standish Group. -Rezhim dostupa: https://www.standishgroup.com/sample_research_files/BigBangBoom.pdf (Data obrashhenija: 01.11.2017).
7. PMI's Pulse of the Profession [Jelektronnyj resurs]. - Jelektron. tekstovye dan. -Project Management Institute. - Rezhim dostupa: https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf (Data obrashhenija: 01.11.2017).
8. KPMG's Project Management Survey 2017 [Jelektronnyj resurs]. - Jelektron. tekstovye dan. - Project Smart. - Rezhim dostupa: https://assets.kpmg.com/content/dam/kpmg/nz/pdf/July/projectmanagementsurvey-kpmg-nz.pdf (Data obrashhenija: 01.11.2017).
9. Kerzner H. Project Management: A Systems Approach to Planning, Scheduling, and Controlling 11th Edition / Harold Kerzner. - Hoboken, NJ, USA: John Wiley & Sons, 2013. -1296 p. - ISBN: 9781118022276.
10. Verzuh E. The Fast Forward MBA in Project Management / Eric Verzuh. - Hoboken, NJ, USA: John Wiley & Sons, 2012. - 544 p. - ISBN: 9781118073773.
11. Berkun S. Making Things Happen: Mastering Project Management (Theory in Practice), Revised Edition / Scott Berkun. - Sebastopol, CA, USA:O'Reilly Media, 2008. - 544 p. - ISBN: 9780596517717.
12. Selihovkin I. Upravlenie IT-proektom. Jeffektivnaja sistema «s nulja» v ljuboj organizacii. [Jelektronnyj resurs] / Ivan Selihovkin. - Jelektron. tekstovye dan. - PMlead. -Rezhim dostupa: http://pmlead.ru/books.html (Data obrashhenija: 01.11.2017).
