Текст книги "Цифровая трансформация для директоров и собственников. Часть 2. Системный подход"

Lean Six Sigma

Lean Six Sigma – гибрид, сочетающий японскую и американскую концепции:

– Бережливое производство (Lean) – сокращение потерь и ускорение процессов, стандартизация и постоянное развитие, работа с людьми и обдумывание;

– 6 сигм (Six Sigma) – повышение качества продукции и лояльности клиентов; основа – анализ информации, измеримые показатели.

Вообще, я как инженер по базовому образованию считаю, что наилучшие решения – некие гибриды. Нет чистых методологий, которые бы полностью были применимы к жизни. Невозможно использовать какой-либо инструмент на 100%, это становится избыточным и слишком дорогим удовольствием. Расчет буровых скважин, приведенный выше, у меня занял один вечер. И в итоге я получил понимание проблемы. Можно было бы и глубже погрузиться, потратить 2—3 вечера на аналитику, но изменился бы от этого конечный результат? Вряд ли. А это уже потери в бережливом производстве – излишняя обработка.

Резюме 3 главы

Конечно, здесь не все инструменты перечислены, и в той же концепции 6 сигм можно глубже рассмотреть контрольные карты Шухарта, DMAIC, DMADV, какие есть роли у персонала (зеленые, черные пояса, мастера и т.д.), а в бережливом производстве – SIPOC и Poka-yoke, «Дом TPS» (инструменты и принципы), но как мне кажется, для тебя, мой читатель, это будет перебором. Ты – не исполнитель, а руководитель. А значит, конкретные инструменты должны знать твои люди, а ты должен понимать, как это работает, чтобы уметь правильно ставить задачи и делегировать, контролировать и спрашивать результат.

Главная цель этой главы – рассеять туман перед загадочным бережливым производством и показать, что это отличный инструмент в комплексной системе управления. И если сначала провести оптимизацию процессов по бережливому производству, а затем при внедрении цифровых инструментов ориентироваться на устранение потерь и работу с людьми, сбор обратной связи от них, то эффект от такого подхода будет измеряться не в нескольких десятках процентов, а кратно.

Как я уже приводил пример, понимая, какие потери надо устранять, как собирать информацию с низов и подкреплять это порой бесплатными инструментами, можно экономить бизнесу миллионы рублей. Так, мы за 4 месяца полностью исключили нецелевую работу у руководителя производства, а это больше 1 миллиона рублей в год, при этом он стал заниматься тем, чем должен – организацией работы подразделения. То же самое касается начальника цеха.

Также QR-код и ссылка для погружения в тематику.

Бережливое производство. Часть 2 +6 сигм

Глава 4. Проектное управление

Из-за некачественного управления страдает абсолютное большинство проектов. Допустим, вы верно определили, куда надо внедрять IT, саму технологию, ключевые эффекты, но вот начинается внедрение и…

Если быть откровенным, то именно с проектного управления начинался мой путь в цифровизации, и именно это направление менеджмента я осваивал наиболее глубоко. В итоге у меня есть опыт работы как со стартапами, так и с гигантами: ЛУКОЙЛ, Газпром, Минэнерго, Mazda-Sollers. И я могу с уверенностью сказать, что в промышленности проектами у нас управлять не умеют: выбирают неверные орг. структуры, методологии, фокусируются на формальных инструментах, не прорабатывают цели, задачи, доступность ресурсов, риски… Но не думайте, что мы такие одни. Вот к каким выводам о причинах неудач в проектах пришла Standish Group после изучения более 50 000 проектов во всем мире:

– Недостаток ресурсов

Это вообще типовая история – давайте инициируем проект, а как реализовать, разберемся потом. Так, у меня был проект в одной корпорации, где участвовало 7500 человек, который мы сопровождали с помощью Exсel. Нужно ли рассказывать об этом веселом приключении, и о том, какого качества данные там были?

– Нереальные сроки

Думаю, всем знакомо «надо было вчера». Нереальные сроки – не так уж и плохо, если мы держим в голове, что они будут сорваны, и пытаемся стать лучше. Но как показывает практика, такого подхода почти не придерживаются.

– Ошибки формулирования целей

Как правило, цели или размыты, или неконкретны, а также бывает ошибка в причинно-логической связи, и цели не отражают тех задач, которые надо решить.

– Недостаточно детальное планирование

Если подумать, то это является первопричиной для всех остальных пунктов.

– Низкое качество взаимодействия внутри команды

К сожалению, внутри корпораций люди привыкли к формальному общению, через записки и переписки. А ведь большинство проблем можно было бы решить просто нормальным общением до наступления последействий.

– Изменение целей в ходе проекта

Опять же, при нормальной проработке стадий инициации и планирования этого можно избежать. А люди крайне плохо переносят хаос и неопределенность.

Статистика проектного управления

Прежде чем погружаться в эту тему, хочу привести диаграмму со статистикой проектного управления:

Статистика проектного управления по классической и гибкой модели

Причем, если глубже погрузиться в исследования, то с 1990-х по начало 2000-х динамика была положительной, а потом все застопорилось. Даже по отраслям ситуация не отличается значительно.

Статистика проектного управления по отраслям

Ну, и на закуску – зависимость успешности от масштаба.

Успешность проектов в зависимости от масштаба и подхода

Давайте посмотрим на наши компании. Все тяготеют к мегапроектам и, желательно, по каскадной (водопадной) модели. Что это и в чем разница – разберем как раз в этой главе.

Еще интереснее выглядит статистика превышения сроков и перерасходов:

Статистика перерасхода средств и превышения сроков

То есть в среднем бюджет превышается наполовину, а сроки – почти вдвое. И это полностью совпадает с тем, что говорят руководители проектов неформально.

Получается, для того, чтобы успешно реализовывать проекты по цифровой трансформации, лучше делать не мегапроект, а большое количество маленьких по гибким методологиям. Необычно, не так ли? Ведь это требует совершенно иной корпоративной культуры, в отличие от того, что мы привыкли видеть.

При этом компетенция проектного управления становится все более обязательной, игнорировать ее нельзя, и вот почему:

– доля проектов в ВВП, например, Великобритании, за 100 лет увеличилась с 5 до 35%;

– мировой тренд – продажа не отдельных продуктов, а комплексных проектов. И мы в этом направлении отстаем на целое поколение. Если все приходят к тому, что надо продавать не газовую турбину, а сервис под ключ, с поставкой, монтажом, всем вспомогательным оборудованием, организацией технического обслуживания, то мы до сих пор продаем саму железку, а дальше – забота клиента;

– по некоторым прогнозам, к 2030 году до 60% рабочего времени руководителя топ-уровня будет уходить на проекты;

– при этом, согласно рекомендациям стандартов и по моим наблюдениям, ошибки, допущенные и не устраненные в начале проекта, могут его гарантированно похоронить. Я проходил и через мертвые проекты, и вытаскивал «проблемные». И стоимость одинаковых изменений растет с 10 условных рублей на стадии инициации и планировании до 10000 при запуске в эксплуатацию. При этом возможности по исправлению ошибок уменьшаются. Поэтому современные методики предусматривают до 30—40% времени от всего проекта на его планирование и проработку рисков.

Возможные подходы и стандарты к управлению проектами

В мире и, в частности, в России существует ряд стандартов и подходов к управлению проектами:

1. Стандарты про компетенции руководителя:

– стандарт ICB от IPMA (Международная ассоциация управления проектами);

– стандарт НТК от СОВНЕТ, который является переводом ICB;

2. Стандарты, выстраивающие процессы:

– PMBOK от PMI

– ISO 21500 от ISO является конспектом PMBOK (100 страниц вместо 500+)

– P2M от PMAJ – и про проекты, и про программы. Ориентирован на ценности, которые должны получить по итогам реализации.

– Prince2, разработанный авторами ITIL, стандарта по управлению ИТ услугами.

– наш ГОСТ Р – краткая версия PMBOK. Отвечает на вопрос «что надо сделать?».

Еще есть Agile как некий свод принципов и инструментов, направленных на гибкость в условиях неопределенности и необходимости тестировать гипотезы, с мощной психологической базой внутри.

Также принято разделять подходы на каскадные и гибкие (agile).

Схематичное отличие каскадного подхода и гибкого

При этом, согласно различным исследованиям, в жизни в основном (60—70%) применяют гибридные методики. Чистого подхода очень мало, и это нормально, ведь невозможно создать универсальный инструмент на все случаи жизни.

Как выбрать правильный подход?

Прежде чем разбирать основные подходы, я хочу поделиться одним, по сути, ключевым инструментом, который позволяет на ранней стадии понять, какой перед вами проект, какой стандарт или гибрид уместнее применить.

Это модель Кеневин (Cynefin framework), которая выделяет пять типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).

Модель Киневин – основа для выбора проектного подхода

1. Простая система

Характеристика: причинно-следственные связи ясны и однозначны.

Что делаем: берём лучшие практики.

Порядок действий: Осознай – Классифицируй – Реагируй.

Примеры: повторяющиеся и относительно простые проекты, такие как укладка тротуара во дворе, проведение вебинара.

Использовать можно любой «каскадный» стандарт. Главное – не обольщаться простотой и не пренебрегать планированием и точками контроля.

2. Сложная система

Характеристика: причинно-следственные связи существуют, но не всегда очевидны.

Что делаем: используем хорошие практики и стандарты. Здесь не существует единственной «лучшей практики», но есть множество «хороших практик».

Порядок действий: Осознай – Проанализируй – Реагируй.

Примеры: внедрение ERP-системы, реконструкция производственной линии.

Здесь необходимо соблюдать требования PMBOK, Prince2, P2M, работать с заинтересованными сторонами и рисками.

«Гибкие» методологии здесь могут привести к необоснованному перерасходу бюджета и срыву срока. Но они могут применяться как элемент «гибридного» подхода.

3. Запутанная система

Характеристика: причинно-следственные связи не ясны. Схожие действия приводят к разным результатам из-за внешних факторов.

Что делаем: здесь поле для гипотез и экспериментов. В таких системах сложно полагаться на историческую информацию и отдельные наблюдаемые со стороны факты. Необходимо самостоятельно изобрести практики достижения результатов.

Порядок действий в такой среде: Исследуй – Осознай – Реагируй.

Примеры: разработка нового мобильного приложения, выход на новый зарубежный рынок, создание законопроекта в области искусственного интеллекта.

Это территория Agile и Scrum. Здесь не подходят четкие технические задания. Необходима гибкость и осознание рисков, отступление от жестких требований.

Придется много общаться с заказчиком. Как правило, он сам не до конца понимает, что ему надо. Итоговый продукт может значительно отличаться от изначального плана.

Это одна из причин проблемности внедрения ИТ в крупных компаниях. Все делается по бумаге, с ограничениями бюджетов. В итоге приходят к неудобным и дорогим в содержании системам и отсутствию бюджета на доработку, что объясняется следующими тезисами:

– Сделано в соответствии с изначальными требованиями, а значит, проект можно считать успешным. Какие могут быть еще вложения?

– В бюрократических организациях практически невозможно осознать ошибочность в изначальных желаниях или понимании того, что на самом деле нужно. А когда ошибка, наконец, вскрывается, ищут виноватого для наказания.

– Ограничения бюджетных правил. Кто сталкивался с этим, понимает, какая это проблема и сколько съедает времени.

4. Хаотичная среда (кризис, инновации)

Характеристика: причинно-следственные связи отсутствуют. Это переходное краткосрочное состояние либо к простой или сложной системам (при помощи жестких ограничений), либо к запутанной среде (при помощи точечных мер).

Порядок действий в такой среде: Действуй – Осознай – Реагируй.

Что делаем: первый шаг в условиях хаоса – это Действие. Цель – уменьшение хаоса. Затем необходимо ощутить результат этого действия и прореагировать для перевода системы из хаотического состояния в запутанное или упорядоченное. На проверку гипотез просто нет времени, в хаотических системах все происходит невероятно быстро.

Результат зависит от грамотности, смелости и инновационности мышления конкретных управленцев.

5. Беспорядочная среда

Ее особенно трудно распознать из-за множества конкурирующих вариантов. Рекомендация состоит в том, чтобы разбить её на составные части и определить, к какому контексту относится каждая из частей.

Типы организационных структур

Для правильного выбора стандарта управления проектом нужно не только определить, в какой среде будет проходить его реализация, но и тип вашей организационной структуры:

Слабая – проектов много, но они небольшие, без рутины, не критичны для компании. Или же всего один проект, который условно забирает 10—20% ресурсов компании. Если смотреть по модели Киневин, это подходит для простых систем. Такая структура особо требовательна к проработке плана коммуникаций между участниками и к получению обратной связи от менеджера проекта, который обычно не является высоким руководителем.

Сбалансированная – средние проекты, которые могут забирать 20—50% ресурсов компании. Если смотреть по модели Киневин, то это сложные и запутанные системы. Можно применять и в хаотичных структурах, но надо оценивать проект. Например, внедрение ERP или отдельных цифровых проектов.

Сильная — стратегические проекты, где цена ошибки высока для компании, и требуется большое количество ресурсов (более 50%). Это, например, программы по трансформации, комплексной автоматизации, внедрение систем бережливого производства и так далее. Здесь крайне важно прорабатывать этап инициации и планирования, делать короткие контрольные точки между этапами и сохранять гибкость.

Далее мы пройдемся по всем основным стандартам, которые лежат в основе всех подходов. Возможно, для вас как руководителей это покажется лишним, но через понимание инструментов вы сможете выбрать подходящий. А для руководителей крупных компаний это позволит эффективнее управлять командой и не собирать лапшу, которую часто пытаются вешать особо умные менеджеры.

Подходы к реализации проектов

PMBOK

PMBOK (Project Management Body of Knowledge). По-русски, это «свод знаний о проектном управлении». Классификатор процессов (до 2021 года), который говорит, что и когда надо исполнить, чтобы проект достиг заявленных целей.

Этот свод – результат труда американцев в их желании создать универсальную инструкцию. Они хотели уйти от человеческого фактора в управлении и сделать так, чтобы любой, взяв эту инструкцию, мог реализовать проект. По этому своду проводит сертификацию PMI (Project Management Institute – Институт управления проектами).

PMI в том числе выдает сертификат о статусе PMP (Project Management Professional – профессионал в области управления проектами). И именно сертификаты от этой организации хотят видеть у руководителей проектов в больших корпорациях.

PMBOK – наиболее распространенная каскадная, или waterfall методология, которую можно использовать в большинстве проектов (простая и сложная категории по модели Кеневин).

Этот подход первым ввел понятие «проектный треугольник», описывающий баланс между стоимостью, временем и качеством проекта.

Проектный треугольник

При этом, сейчас еще актуальна шестая версия PMBOK, но в 2021 вышла седьмая. В ней идет переход к более гибкому управлению. Стандарт больше не говорит, что делать и когда, а дает инструменты и подсказки, предлагая руководителям самостоятельно определять свои действия.

Это стало ответом на неопределенность и нестабильность современного так называемого VUCA-мира:

– Volatility (нестабильность) – постоянные изменения окружающей среды, запросов клиентов.

– Uncertainty (неопределённость) – практически невозможно что-то прогнозировать и планировать. Теперь стратегическое планирование охватывает не 3-5-10 лет, а 1—2 года. Это следствие политических конфликтов, войн, эпидемий.

– Complexity (сложность) – факторов, которых приходится учитывать, становится все больше. Отсюда, кстати, и такие надежды на системы поддержки и принятия решений на основе искусственного интеллекта.

– Ambiguity (неоднозначность) – информация, которой мы руководствуемся при принятии решений, имеет больше одного смысла и одной трактовки, невозможно быть уверенным, что черное – это черное, а белое – это белое. Постоянно вскрываются факторы, которые могут менять смысл кардинально.

Но в мировой повестке примерно с 2016 года появилась новая аббревиатура – BANI:

– Brittle (хрупкий) – любая система легко и быстро ломается.

– Anxious (тревожный) – постоянные изменения, которыми невозможно управлять и под которые необходимо постоянно подстраиваться, ломая свои планы.

– Nonlinear (нелинейный) – одни и те же действия приводят к разным результатам.

– Incomprehensible (непостижимый) – невозможность ориентироваться в бесконечном потоке противоречивой информации.

Как видим, это, по сути, об одном и том же, поэтому пугаться этих названий не стоит. Ответ на эти концепции – гибкость, путь осторожных проб и ошибок.

Вернемся же к нашей теме, PMBOK. Лично мое мнение таково, что упрощение в новой версии опасно. Если смотреть на ситуационную модель лидерства (о ней поговорим чуть позже), то такой подход актуален для компаний, где уже есть опыт проектного управления. Если же мы говорим про молодые компании без каких-либо компетенций, то им как раз нужны четкие и директивные инструкции. Ту же зависимость я вижу в своей практике: чем ниже уровень компетенций у клиентов, тем больше они хотят, чтобы ты их провел за руку, а лучше – сделал вообще все сам. Даже если ты распишешь, как все устроено, какие есть механизмы и инструменты, для них ценнее понятный и четкий алгоритм: возьми палку, подойди к пальме, ударь по банану. И именно поэтому я пришел к осознанию, что для кардинальной смены в проектном управлении нужен цифровой советник, который будет говорить, что и как делать, и параллельно обучать, чтобы в итоге формировать компетенции.

Поэтому давайте глубже рассмотрим актуальную шестую версию. Она подразумевает каскадную модель и следующие стадии проекта:

– инициацию;

– планирование;

– исполнение;

– мониторинг и контроль;

– завершение.

Вообще, эти стадии надо запомнить, как 14 ДАО Тойота, потому что через эти стадии проходит любой проект. И внутри каждой стадии существуют эти же группы процессов. Такая матрешка.

Распределение потребности в ресурсах по стадиям проекта

Под каждую стадию необходимо выполнить определенные процессы.

Наиболее частые причины проблем – непроработанные этапы инициации и планирования. Нет четких критериев успешности, не проработаны риски, коммуникации. Из-за них и появляется большая часть тех 70% проблемных и неудачных проектов. В нынешней неопределенности крайне важно на стадии планирования заложить 20—30% на форс-мажоры (главный постулат риск-менеджмента), а ряд практиков из ИТ вообще считает, что до 50%.

При этом указанные выше группы процессов не строго привязаны к этапам проекта. Процессы инициации есть и на стадии закрытия проекта (инициация закрытия, сбора документов и т.д.)

Также PMBOK подразумевает управление:

– Интеграцией

Принятие решений по концентрации ресурсов; попытки предугадать потенциальные проблемы и разрешить их до перехода в критическое состояние; координирование работы над проектом. С помощью интеграции можно находить компромиссы между пересекающимися целями и альтернативными вариантами.

– Содержанием

Например, создание иерархической структуры работ по проекту, определение, планирование, подтверждение и управление содержанием.

– Сроками

Определение состава операций и взаимосвязей между ними, оценка ресурсов и длительности операций, разработка расписания и управление им.

– Стоимостью

Разработка бюджета и контроль затрат. Осуществляется оценка стоимости, разрабатывается бюджет расходов, производится управление стоимостью.

– Качеством

Все процессы, связанные с выполнением целей. К ним относятся планирование, обеспечение и контроль качества.

– Человеческими ресурсами

Организация проектной команды и управление ей. Планирование человеческих ресурсов, набор и развитие коллектива.

– Коммуникациями

Планируются коммуникации, распространяется информация, создается отчетность по исполнению, происходит управление участниками проекта.

– Рисками

Процессы, относящиеся к данной области, – это планирование управления рисками, идентификация, качественный и количественный анализ рисков, планирование реагирования, мониторинг и управление рисками.

– Поставками

Планирование покупок и контрактов, запрос информации у поставщиков, подбор поставщиков, администрирование и закрытие контрактов.

Резюме

Лично я в практике делаю упор на управление коммуникациями и людьми, работу с поставщиками, заказчиками и интеграцию. Через это мы быстрее узнаем о рисках, возможных проблемах с качеством или сроками, контрагентами. Это помогало мне реализовывать проекты в разных отраслях и с разными людьми. Даже когда я понятия не имел о проектном управлении.

Проблемы в коммуникации также становятся причинами проблем в реализации проектов. Излишний упор на формальные инструменты не спасет вас от проблем, скорее наоборот, выстроит барьеры в общении.

Если же говорить про сам подход, то я бы рекомендовал молодым компаниям начать с шестой версии, немного подрасти «ментально», а дальше переходить к седьмой версии стандарта. Или же найти консультанта, который поможет сразу пройти путь построения проектной культуры по седьмой версии стандарта. Тут вопрос ресурсов: времени и денег – чего у вас больше.

PRINCE 2

Скажу честно, в России я этот подход не встречал. Он у нас не особо распространен, но это не значит, что знать о нем не надо.

PRINCE2 (PRojects IN Controlled Environments – проекты в контролируемых средах) – наиболее директивный метод управления проектами. Он делает акцент на обязательности всех инструментов (процессов, тем, принципов) и опускает важность soft skills (лидерство, работа с мотивацией и так далее). Все как у нас любят менеджеры – акцент на инструментах и системе с игнорированием личных качеств руководителя. Ключевая же задача стандарта, по задумке создателей, обеспечивать правильной информацией в правильное время правильных людей для принятия правильных решений.

Но и он уже ориентируется на AGILE. Например, выдаются сертификаты PRINCE2 Agile Foundation и PRINCE2 Agile Practitioner.

Главное отличие от PMBOK, объясняющее, какие части процесса могут включаться в зависимости от ситуации, что нужно на входе процесса, что в результате, какие нужны инструменты, заключается в том, что PRINCE2 предполагает строгую последовательность шагов для ряда повторяющихся процессов. Но так же, как и PMBOK, его можно отнести к водопадным подходам. Хорошо ли это? Все зависит от ситуации и команды. Кроме того, столь строгий подход не отличается высокой результативностью. Я считаю, что строгость и директивность нужна там, где низкое качество персонала и не предполагается работа по его развитию.

PRINCE2 базируется на 7 принципах, 7 темах, 7 этапах.

7 принципов:

– Постоянная оценка целесообразности

Необходимо, чтобы даже внутренний заказчик был постоянно уверен в необходимости реализации проекта. Как только такая необходимость отпала, проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.

– Учет предыдущего опыта

Необходимо вести базу знаний и ретроспективный анализ проектов. Руководители проектов должны постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе своего проекта.

Это самый важный принцип во всех методологиях, даже в Agile / Scrum. Но как показывает практика, у нас в лучшем случае на старте проекта занимаются планированием, а вот записывать, что происходит во время проекта, затем проводить обзор и вносить все в базу знаний – нет, этого практически никто не делает.

Это же подтвердилось и в исследовании Дмитрия Ирешева и СберМаркета. Ознакомиться с исследованием можно по QR-коду и ссылке.

Результаты Исследования проектного управления в РФ 2022

– Определенные роли и обязанности

Необходимо на старте проекта отработать, кто за что отвечает в команде. Должна быть сформирована матрица ответственности. В подходе есть три заинтересованные стороны: бизнес (определяет цели проекта и инвестирует в него), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).

– Управления по стадиям

Проект должен планироваться, отслеживаться и контролироваться по стадиям. В конце каждой стадии обновляется план следующей стадии, с учетом результатов завершающейся текущей стадии. Изменение плана проекта – нормально. Нужно просто отслеживать версии. Между стадиями должны присутствовать точки принятия основных решений, то есть некие чек-поинты.

– Управление по исключениям

Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. В итоге такой подход позволяет экономить время не только высшего руководства и спонсоров проекта, но и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.

– Фокус на продукте

Акцент в проекте должен быть на конечном продукте и его качестве. Это снижает неудовлетворенность потребителей конечного продукта проекта. Вот уже первые упоминания о продуктовом ориентировании.

– Адаптация к внешним условиям

Проектная команда должна понимать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта. Бесполезно, например, в стартапе внедрять все правила, а в корпорации пренебрегать необходимой документацией.

7 тем:

Это направления, которые позволяют реализовать 7 принципов, и поэтому их описание пересекается с принципами. Вы без проблем сможете сопоставить их.

– Оценка экономического обоснования

Позволяет сформировать механизмы для определения, востребован ли, выполним ли и жизнеспособен ли проект. Это направление позволяет реализовать первый принцип. И на основании такого экономического обоснования, с учетом выгоды, затрат и рисков, должно приниматься решение о дальнейшем продолжении проекта.

– Организация

Заинтересованным лицом (стейкхолдером) проекта может быть как один человек, так и организация, группа. Кроме того, есть команда и ее компетенции. И они будут влиять на проект. В проекте должна быть определена и сформирована четкая структура ответственности и обязанностей участников проекта.

– Управление качеством

Необходимо определить продукт проекта, его критерии успешности, те показатели, которые его характеризуют. Например, количество этажей у здания, высота потолков. А затем нужно постоянно отслеживать, соответствует ли результат тому, что запланировано.

– Планы работ

Необходимо перед каждой стадией иметь актуальные планы: план инициации проекта, план создания продуктов, планы исключений и так далее.

– Анализ и управление рисками проекта

Управление рисками должно осуществляться не только при инициации проекта или в момент наступления риска, а на протяжении всего срока реализации проекта. Это вообще больная тема, так что управлению рисками я посвящу отдельный подраздел.

– Управление изменениями содержания

Иногда, точнее почти всегда, в ходе реализации проекта у заказчика возникают дополнительные пожелания. И необходимо эти изменения фиксировать, оценивать влияние на экономическое обоснование (увеличение цены), сроки и вообще возможность реализовать проект. Вдруг вместо лодки с веслами от вас захотят уже боевой корабль? Это очень сложное направление, у меня в практике такое регулярно – договариваешься об одном, а потом выясняется, что имели в виду другое. И именно поэтому сейчас так популярен Agile.

– Принятие решений

По сути, это мониторинг проекта с установленными метриками и сценариями принятия решений «если, то»: как идет проект, какие отклонения есть, достигнем ли целей и так далее.

7 этапов:

Если посмотреть внимательнее, то это те же пять стадий проекта из PMBOK.

– Начало

Назначается руководитель проекта, определяется продукт проекта, его характеристики. В PRINCE руководитель проекта должен заниматься «техническими» деталями и отчитываться перед управляющим комитетом (УК). А УК осуществляет общее руководство проектом, отвечает за успех и за то, чтобы руководитель вел проект согласно выбранному курсу, «политики партии».

– Инициация

Руководитель составляет «устав проекта» с верхнеуровневым планом, где расписаны ключевые этапы, риски и механизмы реагирования.

– Управление

Утверждается структура управления (команда, распределение ролей и ответственности) и устанавливается, как именно будет проходить каждый следующий этап (детализированный план), и что предпринимать в случае внесения проектных изменений (сценарии реагирования).

– Контроль

Здесь необходимо проработать точки контроля: где и на что будем смотреть, как отслеживать внесение изменений в план и согласовывать с УК.

– Реализация

Самый длительный этап, на котором руководитель организовывает работу команд, чтобы рабочие задачи соответствовали поставленным целям. Также здесь руководитель отвечает за приёмку этапов проекта или продукта.

– Управление ограничениями

Определяем, достигаем ли установленных критериев к продукту проекта.

– Завершение

Ретроспективный обзор проекта и его результатов, подготовка отчета для УК.

Ключевые роли:

– Заказчик – человек, оплачивающий выполнение проекта.

– Пользователь – человек, который станет использовать продукт проекта, или человек, на которого повлияют результаты проекта. Иногда заказчик и пользователь могут быть одним и тем же лицом.

– Поставщик – специалист в предметной области. Предлагает свои знания, необходимые для проектирования или создания конечного результата проекта.

– Менеджер проекта отвечает за организацию, планирование и контроль работ по проекту. Отбирает людей для выполнения задач по проекту и руководит ими.

– Проектная группа и ее руководитель выполняют задачи по проекту. Руководители групп наблюдают за детальными аспектами повседневной работы и отчитываются перед менеджером проекта.