В мире уже давно признано, что управление проектами — особая область менеджмента, применение которой дает ощутимые результаты. Профессионалы в этой области высоко ценятся (в США это третья по средней величине оплаты профессия после юристов и врачей), а сама методология управления проектами стала фактическим стандартом управления на многих тысячах предприятий и применяется в той или иной степени практически во всех крупных корпорациях. В прошлом году приняты стандарты управления проектами ANSI, разработан проект стандартов управления проектами ISO 10006.
В нашей стране не все и не всегда правильно понимают предмет управления проектами, часто путая управление проектами с составлением бизнес-планов. В этой статье мы попытаемся кратко охарактеризовать предмет и сущность управления проектами, основываясь на признанных в мире стандартах этой дисциплины, но с учетом принятых у нас подходов и методов.
Управление проектами дает ощутимые результаты во всех областях приложений, чем и объясняется растущая популярность этой технологии. Для руководителей информационных служб она представляет интерес и как технология, которую полезно внедрить на своих предприятиях, и как средство управления собственными проектами, к которым можно отнести и разработку программного обеспечения, и внедрение тех или иных информационных систем, и прочие изменения, носящие уникальный характер и временные по своей природе.
Сущность управления проектами
Проект — это временное предприятие, предназначенное для создания уникальных продуктов или услуг.
«Временное» означает, что у любого проекта есть начало и непременно наступает завершение, когда достигаются поставленные цели, либо возникает понимание, что эти цели не могут быть достигнуты. «Уникальных» означает, что создаваемые продукты или услуги существенно отличаются от других аналогичных продуктов и услуг.
Уникальность продуктов или услуг проекта обусловливает необходимость последовательного уточнения их характеристик по мере выполнения проекта.
В качестве примеров проектов можно привести строительство, разработку любой новой продукции, проведение ремонтных работ, внедрение информационной системы на предприятии, проведение избирательной кампании, съемки кинофильма и многое другое, что отвечает приведенному определению.
Управление проектами — это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям, необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта.
Управление проектами подчиняется четкой логике, которая связывает между собой различные области знаний и процессы управления проектами.
Прежде всего у проекта обязательно имеются одна или несколько целей. Под целями мы будем далее понимать не только конечные результаты проекта, но и выбранные пути достижения этих результатов (например, применяемые в проекте технологии, система управления проектом).
Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей. Обычно в число основных критериев оценки различных вариантов исполнения проекта входят сроки и стоимость достижения результатов. При этом запланированные цели и качество обычно служат основными ограничениями при рассмотрении и оценке различных вариантов. Конечно, возможно использование и других критериев и ограничений, в частности ресурсных.
Для управления проектами необходимы рычаги. Влиять на пути достижения результатов проекта, цели, качество, сроки и стоимость исполнения работ можно, выбирая применяемые технологии, состав, характеристики и назначения ресурсов на выполнение тех или иных работ. Таким образом, применяемые технологии и ресурсы проекта можно отнести к основным рычагам управления проектами.
Кроме этих основных существуют и вспомогательные средства, предназначенные для управления основными. К таким вспомогательным рычагам управления можно отнести, например, контракты, которые позволяют привлечь нужные ресурсы в нужные сроки. Кроме того, для управления ресурсами необходимо обеспечить эффективную организацию работ. Это касается структуры управления проектом, организации информационного взаимодействия участников проекта, управления персоналом.
Информация, используемая в управлении проектами, обычно не бывает стопроцентно достоверной. Учет неопределенности исходной информации необходим и при планировании проекта, и для грамотного заключения контрактов. Анализу и учету неопределенностей посвящен анализ рисков.
Любой проект в процессе своей реализации проходит различные стадии, называемые в совокупности жизненным циклом проекта. Для реализации различных функций управления проектом необходимы действия, которые в дальнейшем именуются процессами управления проектами.
Процессы управления проектами
Управление проектами — интегрированный процесс. Действия (или их отсутствие) в одном направлении обычно влияют и на остальные направления. Такая взаимосвязь заставляет балансировать между задачами проекта — часто улучшение в одной области может быть достигнуто лишь за счет ухудшения в другой. Для лучшего понимания интегрированной природы управления проектами опишем его через процессы, из которых оно состоит, и их взаимосвязи.
Проект состоит из процессов. Процесс — это совокупность действий, приносящая результат. Процессы проекта обычно выполняются людьми и распадаются на две основные группы:
- процессы управления проектами — касающиеся организации и описания работ проекта (которые будут подробно описаны далее);
- процессы, ориентированные на продукт — касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения.
В проектах процессы управления проектами и процессы, ориентированные на продукт, накладываются и взаимодействуют. Например, цели проекта не могут быть определены при отсутствии понимания того, как создать продукт.
Процессы управления проектами могут быть разбиты на шесть основных групп, реализующих различные функции управления:
- процессы инициации — принятие решения о начале выполнения проекта;
- процессы планирования — определение целей и критериев успеха проекта и разработка рабочих схем их достижения;
- процессы исполнения — координация людей и других ресурсов для выполнения плана;
- процессы анализа — определение соответствия плана и исполнения проекта поставленным целям и критериям успеха и принятие решений о необходимости применения корректирующих воздействий;
- процессы управления — определение необходимых корректирующих воздействий, их согласование, утверждение и применение;
- процессы завершения — формализация выполнения проекта и подведение его к упорядоченному финалу.
 |
| Рис. 1. Наложение групп процессов в фазе |
Процессы управления проектами накладываются друг на друга и происходят с разной интенсивностью на всех стадиях проекта, как показано на рис. 1.
Кроме того, процессы управления проектами связаны своими результатами — результат выполнения одного становится исходной информацией для другого. Эти взаимосвязи проиллюстрированы на рис. 2.
 |
| Рис. 2. Взаимосвязи групп процессов управления проектами в фазе |
И наконец, имеются взаимосвязи групп процессов различных фаз проекта. Например, закрытие одной фазы может являться входом для инициации следующей фазы (пример: завершение фазы проектирования требует одобрения заказчиком проектной документации, которая необходима для начала реализации).
В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться.
Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта. Если необходимость его осуществления отпала, очередная инициация позволяет вовремя это установить и избежать излишних затрат.
Взаимосвязи процессов
Процессы инициации
Инициация включает единственный подпроцесс — авторизацию, то есть решение начать следующую фазу проекта.
Процессы планирования
Планирование имеет большое значение для проекта, поскольку проект содержит то, что ранее не выполнялось. Естественно, что планирование включает сравнительно много процессов. Однако не следует считать, что управление проектами — это в основном планирование. Усилия, прилагаемые для планирования, следует соизмерять с целями проекта и полезностью полученной информации.
Напомним, что следует различать цели проекта и цели продукта проекта, под которым понимается продукция (или услуги), созданная или произведенная в результате исполнения проекта.
- Цели продукта — это свойства и функции, которыми должна обладать продукция проекта.
- Цели проекта — это работа, которую нужно выполнить для производства продукта с заданными свойствами.
 |
| Рис. 3. Взаимосвязи процессов планирования |
Взаимосвязи между процессами планирования представлены на рис. 3.
В ходе исполнения проекта эти процессы многократно повторяются. Изменениям могут подвергнуться цели проекта, его бюджет, ресурсы и т. д. Кроме того, планирование проекта — это не точная наука. Различные команды проекта могут разработать различные планы для одного и того же проекта. А пакеты управления проектами могут составить различные расписания выполнения работ при одних и тех же исходных данных.
Некоторые из процессов планирования имеют четкие логические и информационные взаимосвязи и выполняются в одном порядке практически во всех проектах. Так, например, сначала следует определить, из каких работ состоит проект, а уж затем рассчитывать сроки выполнения и стоимость проекта. Эти основные процессы выполняются по нескольку раз на протяжении каждой фазы проекта.
Кроме перечисленных основных процессов планирования имеется ряд вспомогательных процессов, необходимость в использовании которых сильно зависит от природы конкретного проекта:
- планирование качества — определение того, какие стандарты качества использовать в проекте, и того, как этих стандартов достичь;
- планирование организации — определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации;
- назначение персонала — назначение человеческих ресурсов на выполнение работ проекта;
- планирование взаимодействия — определение потоков информации и способов взаимодействия, необходимых для участников проекта;
- идентификация риска — определение и документирование событий риска, которые могут повлиять на проект;
- оценка риска — оценка вероятностей наступления событий риска, их характеристик и влияния на проект;
- разработка реагирования — определение необходимых действий для предупреждения рисков и реакции на угрожающие события;
- планирование поставок — определение того, что, как и когда должно быть поставлено;
- подготовка условий — выработка требований к поставкам и определение потенциальных поставщиков.
Взаимосвязи между вспомогательными подпроцессами, как и само их наличие, в большой мере зависят от природы проекта.
Процессы исполнения и контроля
 |
| Рис. 4. Взаимосвязи процессов исполнения |
Под исполнением подразумеваются процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Регулярное измерение параметров проекта и идентификация возникающих отклонений далее также относится к процессам исполнения и именуется контролем исполнения. Контроль исполнения следует проводить по всем параметрам, входящим в план проекта.
Как и в планировании, процессы исполнения (рис. 4) можно подразделить на основные и вспомогательные.
К основным можно отнести сам процесс исполнения плана проекта.
Среди вспомогательных процессов отметим:
- учет исполнения — подготовка и распределение необходимой для участников проекта информации с требуемой периодичностью;
- подтверждение качества — регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества;
- подготовка предложений — сбор рекомендаций, отзывов, предложений, заявок и т. д.;
- выбор поставщиков — оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов;
- контроль контрактов — контроль исполнения контрактов поставщиками и подрядчиками;
- развитие команды проекта — повышение квалификации участников команды проекта.
Процессы анализа
Процессы анализа включают как анализ плана, так и анализ исполнения проекта.
Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана командой и другими участниками проекта. На стадии планирования результатом анализа плана может быть принятие решения о необходимости изменения начальных условий и составления новой версии плана либо принятие разработанной версии в качестве базового плана проекта, который в дальнейшем служит основой для измерения исполнения. В дальнейшем изложении анализ плана не выделяется в качестве отдельной группы процессов, а включается в группу процессов планирования, делая эту группу процессов по своей природе итеративной. Таким образом, под процессами анализа в дальнейшем понимаются процессы анализа исполнения.
 |
| Рис. 5. Взаимосвязи процессов анализа |
Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования. В силу уникальности проектов эти критерии не являются универсальными, но для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество и стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями.
Процессы анализа также можно подразделить на основные и вспомогательные.
К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:
- анализ сроков — определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным;
- анализ стоимости — определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным;
- анализ качества — мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта;
- подтверждение целей — процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т. д.).
Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:
- оценку исполнения — анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;
- анализ ресурсов — определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов плановым значениям.
В число процессов анализа не включены анализ взаимодействия с целью оптимизации процедур обработки информации, анализ исполнения контрактов с целью своевременного внесения изменений и предотвращения споров и ряд других процессов, которые не носят регулярного характера (как анализ взаимодействия) либо составляют часть включенных процессов (как анализ контрактов).
В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному ранее плану, либо определяется необходимость применения корректирующих воздействий.
Процессы управления
Управление исполнением проекта — это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта. Если исполнение проекта происходит в соответствии с намеченным планом, то управление фактически сводится к исполнению — доведению до участников проекта плановых заданий и контролю их реализации. Эти процессы нами включены в процессы исполнения.
 |
| Рис. 6. Взаимосвязи процессов управления |
Другое дело, если в процессе реализации возникли отклонения, анализ которых показал, что необходимо определение и применение корректирующих воздействий. В этом случае требуется найти оптимальные корректирующие воздействия, скорректировать план оставшихся работ и согласовать намеченные изменения со всеми участниками проекта. Итак, процессы управления предназначаются для определения, согласования и внесения необходимых изменений в план проекта. Такие процессы управления часто называются управлением изменениями и инициируются процессами анализа (рис. 6).
К основным процессам управления, встречающимся практически в каждом проекте, относятся:
- общее управление изменениями — определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту;
- управление ресурсами — внесение изменений в состав и назначения ресурсов на работы проекта;
- управление целями — корректировка целей проекта по результатам процессов анализа;
- управление качеством — разработка мероприятий по устранению причин неудовлетворительного исполнения.
Среди вспомогательных процессов управления отметим:
- управление рисками — реагирование на события и изменение рисков в процессе исполнения проекта;
- управление контрактами — координация работы (суб)подрядчиков, корректировка контрактов, разрешение конфликтов.
Процессы завершения
 |
| Рис. 7. Взаимосвязи процессов завершения |
Завершение проекта сопровождается следующими процессами (рис. 7):
- закрытие контрактов — завершение и закрытие контрактов, включая разрешение всех возникших споров;
- административное завершение — подготовка, сбор и распределение информации, необходимой для формального завершения проекта.
Методы и технологии реализации перечисленных процессов, их интеграция составляют сущность управления проектами. Обратите внимание, что все перечисленные процессы приложимы к проектам любой природы — и к строительным, и к информационным, и к любым другим. Однако имеются и существенные отличия в управлении проектами различных типов. Следует также отметить, что успешное внедрение системы управления проектами связано с определенной организационной перестройкой и с внедрением специализированных программных средств. Перечисленные вопросы, а также специализированные методы решения отдельных задач управления проектами, технология, опыт и проблемы внедрения будут раскрыты в последующих публикациях.
Литература
1. A Guide to the Project Management Body of Knowledge. Project Management Institute Standards Committee, 1996.
2. Либерзон В. И. Основы управления проектами. М., 1997.
3. Эдвард Ферн. Управление проектами Time-to-Profit. М.: Технологии управления Спайдер, 1999.
Источник: www.osp.ru
Как выбрать методологию для управления проектами? Обзор популярных методологий
Елена Филипова, руководитель корпоративного проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»:
Когда я училась в университете, мне повезло бывать на лекциях академика Габдулхаева. Не имея понятия об управлении проектами, он учил нас гибкости применения наших знаний, выбору оптимального метода. Его любимый вопрос на экзамене: «Какой метод приближения лучший?». А правильный ответ гласил: «Лучшего нет, в каждой ситуации лучший метод свой».
Тоже самое можно сказать и о проектном менеджменте: в каждом проекте, и даже в каждой фазе проекта, может быть свой, лучший подход, своя методология. Как выбрать то, что подходит? Чем отличаются популярные методы управления проектами, и в каких проектах их лучше применять?
Основные стандарты управления проектами и страны разработки
Я часто провожу обучение по управлению проектами и почти всегда слышу один и тот же вопрос: чем отличаются разные методологии, и что лучше выбрать. Для меня подобный вопрос сродни «на каком автомобиле лучше ездить?». На этот упрощенный вопрос гораздо легче ответить, ведь все понимают, что прочувствовать разницу в классе автомобиля, выявить плюсы и минусы автопроизводителя может только опытный водитель.
Чтобы понять «что лучше», нужно научиться хорошо управлять автомобилем, в принципе, получить опыт управления в разных ситуациях и на разном покрытии, попробовать несколько марок и моделей, и только тогда можно сделать вывод, какой автомобиль тебе по-настоящему подходит. К сожалению, в случае с управлением этот цикл может оказаться длиною в жизнь.
Кроме того, «пересесть» с одной методологии на другую — это особый проект, который у большинства не получается выполнить быстрее, чем за три года. Поэтому, особенно на старте, хочется подобрать что-то надежное и подходящее.
В мире не так уж и много «официальных» (признанных) методологий, из которых можно выбирать:
При этом большинство (ISO 21500, ГОСТ Р 54869-2011, APMBOK, C-PMBOK) ориентированы на старейший стандарт PMBoK (USA), а другие (P2M, PRINCE2, ICB IPMA) используют собственные подходы.
Что такое методология? Для ее существования необходимо несколько принципиальных моментов:
- Жизненный цикл
- Описание процессов
- Ключевые роли и их функции
- Требования к компетенциям
- Чек-листы качества
- Шаблоны и их образцы
К сожалению, все эти важнейшие элементы никак не связаны с конкретной областью применения методов управления проектами. Ни в одном стандарте вы не найдете рецепта успешного выполнения именно ваших проектов и именно в вашей компании. Приведу простой пример описания процесса руководства и управления проекта из PMBoK:
Смотрите, как все просто: берете план, вводите в информационную систему статус работ и поставляете результаты. И чего только все так с проектами мучаются? Методология как бы концентрируется на внешнем контуре, а специфику исполнения работ отдает на откуп конкретному руководителю проекта. Но в именно специфике почти всегда и кроется «корень зла», именно из-за особенностей компании, ее инфраструктуры, культуры людей и просто характеров участников проекты либо успешны, либо нет.
А где же Agile?
Я уже предчувствую возмущенные голоса поклонников гибких подходов. Но спешу вас успокоить, что помню про Agile, но намеренно не причислила его к кругу других методологий, потому что это… не методология. Тот, кто знаком с историей возникновения Agile знает, что речь идет об особых подходах к производству и управлению. Кратко сформулировать их можно так:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с клиентом важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Даже на основании этого манифеста (2001 г.) можно понять, что так же, как проектные команды не ориентированы на документирование, так и сами идеологи Agile не будут тратить время на детальное описание методологии. Последний Scrum Guide (наиболее популярный фреймворк) изложен менее, чем на 20 страницах в сравнении с более, чем 800 страницами PMBoK. «Практика, практика и еще раз практика» — говорят сторонники Agile.
Сильные и слабые стороны разных подходов
Не ориентируя вас на выбор отдельного подхода, можно говорить об известных преимуществах и недостатках методологий и подходов. Приведу несколько примеров.
«Классический» (PMBoK и его модификации)
PMBoK зародился в 70-х годах прошлого века для обеспечения управления проектами космической и оборонной промышленности США. Это объясняет, как объем документа, число процессов и сложность его применения малыми и средними компаниями.
«PRINCE2»
Первая редакция британского стандарта PRINCE2 вышла в свет в 1989 г. и была направлена на управление правительственными проектами по созданию информационных систем. Это объясняет более строгое отношение PRINCE2 к окупаемости и применению продукта.
«Гибкие подходы» (SCRUM)
Более гибкие подходы к управлению проектами стали активно развиваться с прогрессом компьютеризации и программирования. Существующие стандарты тормозили проекты по разработке программного обеспечения, требовались совершенно новые подходы. Поэтому в 2001 году в США встретились передовые 17 разработчиков и сформулировали контур движения Agile. Одним из наиболее популярных фреймворков стал SCRUM.
Как выбрать то, что подходит?
Мне не хочется особенно умничать, поэтому вместо статистики и приведения результатов исследований расскажу о своем отношении к выбору методологии.
В результате прочтения нескольких стандартов, более 10 лет практики управления проектами в различных сферах и многократных попыток применить методологию на корпоративном уровне (то есть организовать применение методологии всей организацией) у меня сформировалось несколько выводов:
- Компании среднего уровня практически невозможно полностью применить конкретную методологию. Внедрение «во что бы то ни стало» отнимает время и не способствует достижению целей.
- Выбор методологии должен определять конкретный проект или его фаза. Определять подход к управлению должен не руководитель проекта (наиболее удобный ему), а специфика производства продукта и результатов.
- Если вы хотите сократить время на изобретение своего велосипеда – уделите время чтению. Особенно успешные руководители, не зная стандартов применяют то, что в них написано.
- Даже пара обуви, выпущенная в 1000 экземпляров, будет единственным в мире образом стоптана вашими пятками (мое собственное изречение). Даже стараясь применить конкретный подход или метод, делайте это, адаптируясь к вашим особенностям.
Получив задачу по внедрению управления проектами в крупной компании, я сначала ориентировалась на PMBoK. Но быстро поняла, что внедрение всех процессов может занять у меня целую вечность. Даже применяя конкретный инструмент, и даже в том верхнеуровневом виде, в котором он описан в стандарте, мне приходилось вносить в него корректировки, чтобы он был принят персоналом.
Иногда в ходе практики мы находили очень эффективные собственные способы, а затем я отыскивала их прообразы в других стандартах. Так, будучи уверенной, что вношу небольшие корректировки в PMBoK, я начала на уровне методологии использовать регулярные частые и короткие совещания с командой (прообраз Daily Scrum Meeting), применять для фаз и ключевых результатов критерии успеха (аналог Scrum Acceptance Criteria) и многое другое.
Столкнувшись с крупными проектами, которые в комплексе должны производить несколько разных продуктов (стройка, ИТ-решение, организация) пришлось учесть в методологии возможность гибридного управления (для ИТ – Agile, для стройки – прообраз PMBoK), что отлично сработало.
С приходом в компанию ADVANTA мне снова пришлось выстраивать работу внутреннего Офиса управления проектами. И многие наработки из крупного бизнеса пришлось забыть, изменить требования к процессам, глубину описания и используемые документы.
Уверена, что, проявив достаточное упорство в предоставлении удобного формата для работы и знания по наиболее популярным подходам (а их немного) сотрудникам компании, можно сделать действительно работающий проектный офис, которым довольны и руководство, и менеджеры проектов. Кстати, оценка работы моего проектного офиса по итогам 2019 года составила 9,3 из 10 баллов (оценивался вклад проектного офиса в области управления проектами).
Чтобы дойти до цели, человеку нужно только одно. Идти.
Оноре де Бальзак
Рекомендуем посетить популярные страницы сайта:
Источник: www.advanta-group.ru