По нашему наблюдению, в стране почти везде к проектам относятся как ко вторичному и отвлекающему элементу. Однако, по некоторым данным, к 2025 году до 60% рабочего времени руководителей будет уходить именно на проекты. А по нашим исследованиям уже сейчас, в 2023 году до 50% времени руководителей приходится на управление проектами.
Это подтверждается и мировым опытом - все больше компаний начинают продавать комплексные проекты/продукты для полного удовлетворения потребностей клиентов и повышения своей прибыли.
При этом, ошибки, допущенные и не устраненные в начале проекта, могут его гарантированно похоронить, а стоимость изменений на стадии запуска проекта в эксплуатацию в 1000 раз больше, чем на стадии инициации и планировании.
А возможности по исправлению ошибок в ходе реализации проекта уменьшаются.
Поэтому современные методики предусматривают до 30-40% времени от всего проекта как раз на его планирование и проработку рисков.
Содержание:
С чего начать?
Прежде чем пускаться в стандарты управления, нужно определить, какого типа проект перед вами.
Для этого отлично подходит модель Киневин, которая была разработана Дейвом Сноуденом еще в 1999 году и основана она на том, что «разные проблемные ситуации требуют разных подходов к поиску правильного решения», как говорил сам Сноуден.
Модель выделяет пять типов систем: простые, сложные, запутанные, хаотические и беспорядочные (или неопределенные).
Простая система
Как правило, это повторяющиеся и относительно простые линейные проекты. Например, установка базовой станции мобильной связи, укладка тротуара во дворе, проведение вебинара. В такой системе можно работать по любому "каскадному" стандарту (”водопад”). Главное не обольщаться простотой и не пренебрегать планированием и точками контроля.
Сложная система
Характеризуется увеличением количества взаимосвязей. Создание медицинского центра, внедрение ERP-системы, реконструкция производственной линии - всё это можно отнести к сложным системам. Здесь необходимо соблюдать ключевые требования стандартов PMBOK, Prince 2, P2M, работать с заинтересованными сторонами и рисками. "Гибкие" методологии здесь могут привести к необоснованному перерасходу бюджетов и срывов сроков. Но они могут применяться как элемент "гибридного" подхода.
Запутанная система
Количество взаимосвязей увеличивается в разы, что уничтожает линейность процессов. Это такие проекты, как, например, разработка нового мобильного приложения, выход на новый зарубежный рынок, создание законопроекта в области искусственного интеллекта.
В таких проектах приходится много общаться с заказчиком. Более того, он сам не до конца понимает, что ему надо, и итоговый продукт может значительно отличаться от изначального плана.
Следовательно, управлять таким проектом надо гибко. Это территория Agile и Scrum. Здесь не подходят четкие ТЗ, но осознание рисков и готовность отступить от жестких требований - обязательны.
Хаотичная система
Тот самый случай, когда “нет времени объяснять…”. Как правило, это либо кризис, либо инновации.
Первый шаг в условиях Хаоса – это Действие. Цель – уменьшение Хаоса. Затем необходимо ощутить результат этого действия и прореагировать, для перевода системы из хаотического состояния в запутанное или сложное. На проверку гипотез просто нет времени, ведь в хаотических системах все происходит невероятно быстро.
Результат зависит от грамотности, смелости и креативности конкретных управленцев.
Беспорядочная система
Это система, которую сложно отнести к той или иной категории. Лучше всего будет разбить ее на составные части и классифицировать их по отдельности.
Свод характеристик, рисков и рекомендаций по типам систем - во вложении:
Теперь, когда вы определились с типом своего проекта, нужно выбрать стандарт управления им.
Сейчас применяются в основном гибридные методики. Чистого подхода очень мало. К ним относятся:
К классическим подходам относится так называемый “Водопад” (Waterfall) - тот самый необходимый базовый уровень управления. Сегодня в чистом виде практически не используется, но именно из “Водопада” выросли такие философии, как тот же “Agile”.
Согласно каскадному подходу, проект делится на пять этапов: сбор требований, проектирование, реализация, тестирование, развертывание.
Команда проекта движется последовательно от этапа к этапу.
Главное в такой схеме - это согласованное техническое задание. Оно есть Бог всего проекта с четким планом, инструкциями, формальностями и ограничениями. Это тот тип управления, который свойственен государственным структурам и крупным корпорация. ТЗ здесь - 50% всего успеха.
Соответственно, он не подходит сложным, запутанным и уж тем более хаотичным проектам.
Ведь все делается по ТЗ и с ограничением бюджетов. Сам же успех продукта оценивается относительно изначальных требований. Если соответствует, то проект считается успешным. А следовательно, зачем вкладываться в его доработку? Но если, несмотря на соответствие ТЗ, организация осознает ошибочность решения, то обычно недовольство выражается в наказании ответственных.
Однако для простых проектов или для некоторых этапов сложных и запутанных проектов каскадный метод вполне подходит.
Project Management Body of Knowledge - по-русски, это свод знаний о проектном управлении, "классификатор" процессов, диктующий что и когда надо исполнить, чтобы проект достиг заявленных целей.
Этот свод - результат труда американцев в их желании создать универсальную "инструкцию". Они хотели уйти от человеческого фактора в управлении и сделать так, чтобы любой, взяв эту инструкцию, мог реализовать проект. По этому своду проводит сертификацию PMI (Project Management Institute - Институт управления проектами).
PMI в том числе выдает сертификат о статусе PMP (Project Management Professional - профессионал в области управления проектами).
PMBOK - наиболее распространенная каскадная, или waterfall-методология, которую можно использовать в большинстве простых и сложных проектах.
Этот подход ввел понятие "проектный треугольник", описывающий баланс между стоимостью проекта, временем и качеством:
Сейчас еще актуальна шестая версия PMBOK, но в 2021 вышла седьмая. В ней идет переход к более "гибкому" управлению. Стандарт больше не диктует, что и когда делать, а дает инструменты и подсказки. Вы сами будете ориентироваться в обстоятельствах.
Это стало ответом на неопределенность и нестабильность. так называемой концепции VUCA-мира.
Актуальная шестая версия делает упора на каскадную модель и следующие стадии проекта: инициацию, планирование, исполнение, мониторинг и контроль, завершение.
Под каждую стадию необходимо выполнить определенные процессы.
Наиболее частые причины проблем - непроработанные этапы инициации и планирования, когда нет четких критериев успешности, не проработаны риски, коммуникации.
В нынешней неопределенности крайне важно на стадии планирования заложить 30-35% на форс-мажоры (главный постулат риск-менеджмента), а ряд практиков из ИТ вообще считают, что эта цифра должна быть на уровне 50%.
При этом указанные выше группы процессов не строго привязаны к этапам проекта. Процессы инициации есть и на стадии закрытия проекта (инициация закрытия, сбора документов и т.д.)
Также PMBOK подразумевает управление:
Интеграцией
Принятие решений по концентрации ресурсов; попытки предугадать потенциальные проблемы и разрешить их до перехода в критическое состояние; координирование работы над проектом. С помощью интеграции можно находить компромиссы между пересекающимися целями и альтернативными вариантами.
Содержанием
Например, создание иерархической структуры работ по проекту, определение, планирование, подтверждение и управление содержанием.
Сроками
Определение состава операций и взаимосвязей между ними, оценка ресурсов и длительности операций, разработка расписания и управлением им.
Стоимостью
Разработка бюджета и контроль затрат. Осуществляется оценка стоимости, разрабатывается бюджет расходов, производится управление стоимостью.
Качеством
Все процессы, связанные с выполнением целей. К ним относятся планирование, обеспечение и контроль качества.
Человеческими ресурсами
Организация проектной команды и управление ей. Планирование человеческих ресурсов, набор и развитие коллектива
Коммуникациями
Планируются коммуникации, распространяется информация, создается отчетность по исполнению, происходит управление участниками проекта.
Рисками
Процессы, относящиеся к данной области, – это планирование управления рисками, идентификация, качественный и количественный анализ рисков, планирование реагирования, мониторинг и управление рисками.
Поставками
Планирование покупок и контрактов, запрос информации у поставщиков, подбор поставщиков, администрирование и закрытие контрактов.
Лично мы делаем упор на управление коммуникациями и людьми, работу с поставщиками, заказчиками и интеграцию.
Через это мы быстрее узнаем о рисках, возможных проблемах с качеством или сроками, контрагентами. Это помогало реализовывать проекты в разных отраслях и с разными людьми.
Проблемы в коммуникации также становятся причинами проблем в реализации проектов. Излишний упор на формальные инструменты не спасет вас от проблем, скорее наоборот, выстроит барьеры в общении.
При кажущейся простоте подхода, осваивать его надо долго и упорно. Взаимосвязи внутри проекта выглядят следующим образом:
Самостоятельно можете изучить стандарт и книги на его основе здесь:
Видео на тему:
PRojects IN Controlled Environments 2 (проекты в контролируемых средах, вторая версия) - наиболее "директивный" метод управления проектами. Он делает акцент на обязательность всех инструментов (процессов, тем, принципов) и опускает важность soft skills (лидерство, работа с мотивацией и так далее). Всё, как у нас любят.
Но и он уже ориентируется на AGILE. Например, выдаются сертификаты PRINCE2 Agile Foundation и PRINCE2 Agile Practitioner.
В отличие от руководства PMBoK, где объясняется, какие части процесса могут включаться в зависимости от ситуации, в структурном стандарте PRINCE2 предполагается чёткая последовательность этапов (шагов) для ряда повторяющихся процессов.
Но так же, как и PMBoK, его можно отнести к "водопадным" подходам.
Создатели методологии считают, что использование PRINCE2 помогает обеспечить правильной информацией в правильное время правильных людей для принятия правильных решений.
Стандарт включает в себя 7 принципов, 7 тем, 7 процессов.
7 принципов:
Постоянная оценка целесообразности. Заказчик, даже если он внутренний, должен быть постоянно уверен в необходимости реализации проекта, если такая необходимость отпала, то проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.
Учет предыдущего опыта. Руководители проектов должны постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе проекта.
Определенные роли и обязанности. В каждом проекте должна быть сформирована матрица ответственности в рамках проекта и его организационной структуры. Авторы PRINCE2 выделяют три заинтересованные стороны проекта: бизнес (определяет цели проекта и инвестирует его), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).
Управления по стадиям. Проект должен планироваться, отслеживаться и контролироваться по стадиям. В конце каждой стадии должен обновляться план следующей стадии, с учетом результатов завершающейся текущей стадии. Между каждой стадией должны присутствовать точки принятия основных решений.
Управление по исключениям. Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Такой способ управления позволяет экономить как время высшего руководства, спонсоров проекта, так и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.
Фокус на продукте. Акцент в проекте должен быть на конечном продукте и его качестве. Процедура управления изменениями снижает увеличение скоупа проекта. Акцент на качестве и утвержденном описании продукта снижает неудовлетворенность пользователей (потребителей) конченного продукта проекта.
Адаптация к внешним условиям. Проектная команда должна осознавать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта.
7 тем постоянного внимания:
Экономическое обоснование позволяет сформировать механизмы для определения востребованности, выполнимости и жизнеспособности проекта, а также остается ли проект таковым на протяжении всего его выполнения. На основании экономического обоснования с учетом выгоды, затрат и рисков должно приниматься решение о дальнейшем продолжении проекта и его инвестициях.
Организация. Заинтересованными лицами проекта являются лицо или группа лиц, которая может влиять на проект или на которую может влиять проект (включая процессы и риски проекта). В проекте должна быть определена и сформирована четкая структура ответственности и обязанностей проекта. Подробное описание каждой роли можно прочитать в стандарте.
Управление качеством. Определение и внедрение средств в рамках проекта для подтверждения, что продукты проекта соответствуют утвержденному описанию и подходят для тех целей, для которых они предназначены. Любой продукт проекта должен обладать определенным комплексом свойств и неотъемлемых или установленных характеристик, которые дают понимание, что продукт отвечает ожиданиям или удовлетворяет установленным потребностям, требованиям или спецификации.
Планы работ – широко описывает понятия и уровни планов в проекте (план стадии инициации проекта, план самого проекта, планы стадий создания продуктов, планы исключений, планы команды).
Анализ и управление рисками проекта. Управление рисками должно осуществляться не только при инициации проекта или в момент наступления риска, а на протяжении всего срока реализации проекта. Тема анализа и управления риска предоставляет подход к выявлению, оценке и контролю рисков во время проекта и, как результат, повышению успеха проекта.
Управление изменениями содержания = определение, оценка и последующее управление любыми потенциальными и одобренными изменениями конечных продуктов проекта. При управлении изменениями всегда должен использоваться предыдущий опыт, запросы на изменения и отклонения от спецификации должны оцениваться с точки зрения влияния на экономическое обоснование проекта.
Принятие решений – предназначена для формирования и утверждения механизмов мониторинга фактических результатов и достижений проекта и их сравнение с запланированными, прогнозирование целей проекта и его отклонения.
7 процессов:
Начало. Назначается руководитель проекта, а также устанавливаются требования к характеристикам и качеству продукта. Руководитель проекта должен заниматься деталями и отчитываться перед Управляющим комитетом (УК). Комитет же, в свою очередь, осуществляет общее руководство проектом, отвечает за его успех и следит, чтобы проект придерживался выбранного курса.
Инициация. Руководитель составляет «инициирующий документ». В нём описывается верхнеуровневый план, где расписаны пути достижения цели. После подписания документа УК, начинается этап управления. Длительность фаз может быть разнообразной, но последовательность сохраняется строго, как и в традиционном проектном менеджменте.
Управление. Утверждается структура управления и устанавливается, как именно будет проходить каждый следующий этап, и что предпринимать в случае внесения проектных изменений.
Контроль. Даже в благоприятных условиях при реализации проекта в него вносятся изменения. Поскольку «дорожная карта» следующей стадии создаётся после детального анализа прохождения предыдущей стадии, проект в таком формате естественным образом адаптируется к изменениям. Такие изменения вносят коррективы и в план проекта, который обязательно согласовывается с УК.
Реализация. Основной этап, в ходе которого реализуются операции по проекту. Руководитель на этой стадии следит, чтобы весь состав команды выполнял свои задачи, которые соответствовали бы поставленным целям. Также здесь руководитель отвечает за приёмку частей проекта.
Управление ограничениями. На этом этапе определяется, получается ли создавать то, что нужно бизнесу, решаются ли вопросы по продвижению процесса и условиям реализации.
Завершение. На завершающем этапе происходит глубокий анализ хода реализации проекта и его результатов. Отчёт об этом представляется УК.
Роли:
Заказчик — человек, оплачивающий выполнение проекта.
Пользователь — человек, который станет использовать продукт проекта, или человек, на которого повлияют результаты проекта. Иногда заказчик и пользователь может быть одним и тем же лицом.
Поставщик — специалист в предметной области. Предлагает свои знания, необходимые для проектирования или создания конечного результата проекта.
Менеджер проекта отвечает за организацию, планирование и контроль работ по проекту. Отбирает людей для выполнения задач по проекту и руководит ими.
Проектная группа и ее руководитель выполняют задачи по проекту. Руководители групп наблюдают за детальными аспектами повседневной работы и отчитываются перед менеджером проекта.
Администратор организует совещания, держит всех участников в курсе дел, следит за документацией и т. д. При работе над небольшими проектами менеджеры проектов часто берут эти обязанности на себя. Но в основном организуется служба административной поддержки, которая занимается выполнением этих обязанностей.
Краткое изложение стандарта:
Видео на тему PRINCE2:
Японский подход, скорее даже система знаний по управлению проектами. Он базируется на практическом опыте японских компаний и нацелен на создание ценности для клиентов в проектах, где высока доля неопределенности.
Его цель - создание условий для создания большей добавленной стоимости плюс исключение ситуации, когда к закрытию проекта его результат/продукт никому не нужен, или нужен, но в другой форме.
P2M делает акцент на том, какую ценность мы создаем для потребителя продукта, учит нас понимать, кому и для чего нужен продукт. И этим он максимально приближается к современному тренду - продуктовому управлению.
Если PMBOK (5 редакция, самая распространенная у нас) определяет проект как "временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов указывает на определенное начало и окончание”, то Р2М говорит о проекте, как об “обязательстве создать ценность, основанную на миссии проекта, которое должно быть завершено в определенный период в рамках согласованных времени, ресурсов и условий эксплуатации”.
Любой проект начинается с определения его миссии. Это отличает Р2М от других стандартов по управлению проектами, где обычно начинают с определения целей.
Основной документ P2M — Руководство по управлению инновационными проектами и программами предприятий.
P2M признает в качестве ограничений не только содержание, ресурсы и сроки, но и внешние обстоятельства
И самое важное: P2M нацелен на управление не одним проектом, а программой или портфелем проектов, чтобы они были синхронизированы и объединены общей целью / миссией всей компании. То есть он смотрит на проект, как на элемент взаимосвязанной системы.
По своему опыту и анализу проектов разных компаний, в том числе по внедрению цифры и трансформации, можем сказать, что это один из самых критичных и болезненных вопросов. Это условие, как правило, не соблюдается.
Японцы относят P2M к третьему поколению стандартов:
1 поколение
Основа состояла в определении целей по стоимости, срокам, качеству и содержанию для достижения стабильно высоких результатов (я бы отнес к ним PMBOK ранних редакций)
2 поколение
В дополнение к проектной деятельности акцентировалось внимание на операционной деятельности для получения ожидаемых результатов, удовлетворяющих всех заинтересованных лиц (для меня это PRINCE2)
3 поколение
В отличие от двух других поколений, которые делают акцент на внутренней среде проекта, здесь присутствует акцент на изменении окружения проекта и на поиске решений сложных миссий для увеличения ценностей компании, а также на использовании лучших сторон задействованных проектных команд. Именно к этому поколению и относится P2M. Я бы отнес сюда также Agile/Scrum и седьмое поколение PMBOK.
Для определения миссии используется метод 6W1H (Who, What, When, Why, How, Which and Whom) с ответами на вопросы:
Кто менеджер программы?
Что будет главной проблемой и ее решением?
Когда будет начало и окончание программы?
Почему она создаётся?
Как она будет реализована?
Который из планов будет реализован?
Кому будет выгоден результат?
Это вариация инструмента 5W1H (What, When, Why, Who, Where and How), которым пользуются для формулирования проблем в бережливом производстве.
В итоге получается краткий план управления программой:
Описание: адаптация к внешним изменениям и выполнение общей миссии компании
Общее представление: понимание специфичных элементов, для реализуемых программ
Общие основы: установка главной цели управления программами
Управление интеграцией: создание ценностей компании и общая оптимизация управления в ней.
Чем надо управлять в проекте:
Стратегией проекта: отношение между корпоративными стратегиями и проектами. Направление эффективного выполнения проектных активностей в соответствии с корпоративными ценностями;
Финансами: создание и подготовка базы для проведения мобилизации необходимых для проектов денег;
Организацией проекта: возможности организации работ для быстрой и гибкой реакции на косвенные изменения внешнего окружения проекта;
Целями: план достижений целей проекта, вследствие чего руководители и команды проектов могут планировать процессы выполнения проекта до самого завершения программы с учетом всех ограничений (в том числе условий контракта и ограниченности ресурсов) и сбалансированно выполнять работы по проекту;
Ресурсами: необходимые для проекта ресурсы и их распределение (материалы, люди, информационные и финансовые ресурсы, интеллектуальные ресурсы и т.д.);
Информацией: подход к подготовке большей части информации в течение проекта;
Коммуникациями: определяет основные принципы и методы коммуникаций на основе полученного ранее опыта с учетом межкультурных коммуникаций;
Рисками: осуществление контроля и реакции на каждый риск;
Отношениями: принципы и методы управления отношениями между стейкхолдерами (заинтересованными);
Ценностями: сбор знаний, опыта и источников, предоставляющих ценности (например, типовые корпоративные или проектные активности) для проектов;
Взаимосвязями: понимание взаимосвязей в проекте и позволяет избегать неоднозначных и неожиданных вопросов во время выполнения проекта.
Основные принципы, применяемые при работе:
В основе инновации и её реализации лежит миссия – глобальная цель, ради которой создавался инновационный продукт.
В результате должен получиться уникальный продукт, приносящий выгоду заинтересованным лицам, а также улучшающий внешнюю среду (общество) и внутреннюю среду компании;
Действия участников команды должны быть взаимосвязанными.
Важнейшую роль в реализации программ играют менеджеры, которые должны иметь стратегическое мышление, навыки к планированию, обладать системными знаниями и быть нацеленными на достижение результата.
Обязательно наличие ментального пространства для всех участников команды (в Японии это пространство называется «Ба» — платформа), в котором идет постоянное взаимодействие и обмен идеями.
Оценка ценности продукта и разработка альтернативных методов решений должна идти постоянно, чтобы в условиях изменяющейся среды план непрерывно развивался в заданном ключе, и программа двигалась к цели.
Ключевые компетенции, для достижения ценности и создания нового продукта:
Осознание миссии программы
Наличие новаторских идей
Стратегическое мышление
Координаторские способности
Ориентированность на результат
Навыки взаимоотношений
Способность укладываться в заданные сроки
От себя скажем, что если вас назначили на проект "сверху", то выбирайте между PMBOK и Agile, в зависимости от степени неопределенности. P2M даст эффект, если его внедрять на уровне всего предприятия.
Сам стандарт можно купить по ссылке.
Видео об P2M:
На этом мы завершаем обзор "классических" методов управления проектами и в следующих частях расскажем о гибких подходах, статистике в проектном управлении и работе с рисками.
***
Мы разрабатываем собственное цифровое решение для ваших проектов. Ознакомиться с ним можно по ссылке: