Стейкхолдер "заказчик", фазы, стадии и контрольные точки

"2.3 заинтересованные стороны проекта

Заинтересованные стороны проекта – это лица или организации (например, заказчики, спонсоры,

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

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

Это делается с помощью описания архитектуры, стандарт ГОСТ Р 57100-2016 (ISO42010-2014).

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

Что такое архитектура системы? Это все важное в устройстве системы. Важное или нет, могут решать только люди. Люди, а точнее, деятельность людей, в системном подходе учитывается стейкхолдерами, заинтересованными лицами. Стейкхолдеры и системные интересы бывают двух видов:

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

Таким образом, стейкхолдеры бывают 1-го и 2-го вида:

1. Задействованные заинтересованные лица. Те, кто будет работать с вашей системой или делать ее. Они непосредственно влияют на проект. К ним минимально относятся - команда и спонсоры проекта и пользователи продукта/системы.
2. Затрагиваемые заинтересованные лица. Те, на кого воздействует деятельность задействованных лиц. Их интересы могут быть затронуты проектом, например, проект реновации Москвы затрагивает жителей соседних со сносимыми домами, хотя новым домом они пользоваться не будут и выгод от участия в проекте не получают. Либо могут быть затронуты самой системой. Например, построенная вместо пятиэтажки 24 этажная "свечка" увеличит нагрузку на водопровод, канализацию, парковочных мест станет меньше, а прекрасный вид из окна будет загорожен.

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

Что означает поговорка "стейкхолдеров всегда на одного больше, чем ты думаешь", которую так любят руководители проектов и системные инженеры? Чаще всего эта поговорка всплывает в ситуации, когда затрагиваемый стейкхолдер получает возможность сделать что-то с вашим проектом или системой и вам приходится учитывать в проекте его интересы и реализовывать его требования. Происходит миграция стейкхолдера. Например, жители Санкт-Петербург заставили перенести башню Газпромнефти из центра города на окраину, некоторые жители домов, попавшие под реновацию, сумели исключить их из программы, а создатели роликов про фаст-фуд сильно повлияли на доходы и товарное предложение МакДональдс, КФС и других сетей быстрого питания.

Т.к. стейкхолдеры - это просто оборотная сторона деятельности (практики = дисциплина + технология), то зачем ввели целое понятие? Причин три.

1. На старте проекта, когда не понятно, где будет физически расположена система, кто будет ей пользоваться, команда проекта еще не собрана, технологии не выбраны, но спонсор проекта уже просит посчитать, сколько это будет стоить и как будет окупаться. Нужны предположения. Предположения абстрактны "нам будет нужно три программиста-разработчика на Java, а пользоваться будут люди, которые хотят сэкономить на занятиях по фитнесу". Создаются ролевые описания, которые описывают поведение стейкхолдеров.
2. Системы с массовым использованием, например, почта или аппа. Тут даже если все технологии выбраны, понятно, кто пользуется и команда есть, все равно надо создать какую-то абстракцию "отправитель бандероли", "получатель срочного заказного письма", чтобы создать модель его деятельности. Опять ролевое описание.
3. Абстракции - это хорошо и они незаменимы для начального планирования, но работать приходится с конкретными людьми. На место программиста Java приходит конкретный Андрей Николаевич, а пользовательские требования к почтовой системе мы будет собирать у конкретной Валентины Петровны. Это "представители стейкхолдеров", они выполняют это ролевое поведение, описанное моделью стейкхолдера.

Аналогия здесь следующая:

Роль::Актер

Стейкхолдер::Представитель стейкхолдера

Другими словами, стейкхолдер - это функциональное/компонентное представление человека, который что-то делает, а представитель стейкхолдера - это конструктивное/модульное представление человека, который что-то делает.

Надо отличать задействованных стейкхолдеров от затрагиваемых стейкхолдеров и стейкхолдеров как роли от представителей стейкхолдеров.

Конкретный спонсор проекта (человек, личность) может выполнять роли "венчурный инвестор" и "финансовый контроле МСФО" (стейкхолдерская роль)

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

Дополнительную путаницу вносят организационные позиции, должности. Оргпозиция используется для моделирования полномочий, ответственности за выполнение, ответственности за результат и подотчетности (authority, responsibility, accountability, governance). Говорить "стейкхолдер генеральный директор" категорически неправильно, т.к. занимаемая должность ничего не дает вам с точки зрения организации и планирования работ. Оргпозиции важны для процесса принятия решений - по выделению ресурсов, например, но не для планов.

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

Нужны доказательства? Откройте любой стандарт по планированию проектов, например,

Practice Standard for Scheduling – Second Edition

Источник <https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-scheduling-2ndedition>

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

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

PMI PMBOK:

Ролевое, компетентностное описание команды проекта. Команда проекта, см. раздел 2.3 PMBOK, является стейкхолдерами.

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

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

Разработка плана управления проектом – это процесс документирования действий, необходимых для

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

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

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

1. Изменить профиль оргпозиции и перераспределить роли между другими оргпозициями
2. Двигать человеческий капитал по жизненному циклу

ПРАКТИКИ ЖИЗНЕННОГО ЦИКЛА ЧЕЛОВЕЧЕСКОГО КАПИТАЛА

Фокус организации на эффективность рабочих мест

Здоровье и благополучие

Оборудование и инструменты

Операционные процедуры

Командная работы и коммуникации

Тренинги рабочих навыков

Отбор персонала

Влияние изменений

Лидерство

Роли и ответственность

Расследования и обучение

Функциональная пригодность персонала

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

Ключевое отличие лидерства от руководства/менеджмента – нет (не используется) прямое распоряжение ресурсами. Добровольное следование команды указаниям, не приказам. Побуждение, использование мотивов, не принуждение.

Это была вводная часть объяснения.

Вы должны понимать различия между:

1. Стейкхолдером (ролью)
2. Представителем стейкхолдера (человеком, назначенным на исполнение этой роли)
3. Оргпозицией в штатной стурктуре (сборник ролей с назначенными полномочиями по распоряжению ресурсами, ответственностью за исполнение работ, ответственностью за результат и подотчетностью другим оргпозициям)
4. Должностным лицом (человеком, назначенным на оргпозицию)

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

https://en.wikipedia.org/wiki/Form_follows_function

И теперь, возвращаясь к ИСО42010:

Системные описания привязываются к стейкхолдерам (ролям), отвечают их интересам (деятельностным интересам, не праздным).

Практическое правило - слышишь интерес, ищи описание (модель), которое на этот интерес ответит. Спрашивают описание (модель), подумай - какой интерес стоит за вопросом, зачем человек это спрашивает, в какой роли он находится, какого стейкхолдера представляет?

Та же схема по версии ГОСТ Р 57100.

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

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

Путаница с заказчиком

Стейкхолдера "Заказчик" не существует.

При первом взгляде на проект все очень просто.

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

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

На стороне заказчика есть 4 стейкхолдера:

1. Пользователь. Ему интересна система и ее функциональность.
2. Приобретающая сторона. Ему интересно когда и сколько, на каких условиях надо платить за проект.
3. Лицо, принимающее решение. Тот, кто решает, каким должен быть продукт и у какого поставщика его будут приобретать.
4. Капиталист. Его интересует, как извлекать пользу, выгоду от системы. 

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

Разбираемся с основными видами документов, которые показывают заказчикам:

1. Жизненный цикл проекта, состоящий из проектных фаз
2. Жизненный цикл продукта, состоящий из продуктовых стадий
3. Дорожная карта
4. Бюджет, как его разновидность - освоенный объем

"2.1 жизненный цикл проекта – обзор

Жизненный цикл проекта – это набор, как правило, последовательных и иногда перекрывающихся фаз

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

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

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

1. Риск продолжать проект высокий, но с ним можно работать. Дается еще немного денег на доработки. Проект в следующую фазу не переводится, новые пакеты работ не авторизуются.
2. Риск продолжать приемлемый. Проект переводится в следующую фазу, авторизуются новые пакеты работ.
3. Риск продолжать неприемлемый. Изменение плана управления проекта, базового плана либо принятие решения о прекращении проекта. Обычно сопровождается проектным аудитом. 

Последние 10 лет идет массовый отказ от понятия "Жизненный цикл проекта", современные проектные методологии оперируют только жизненными циклами продукта. Грубо говоря, весь жизненный цикл продукта рассматривают как проект. В Axelos PRINCE2 фазам соответствуют Gates:
"2.4 Manage by stages A PRINCE2 project is planned, monitored and controlled on a stage-by-stage basis. Management stages provide senior management with control points at major intervals throughout the project. At the end of each stage, the project’s status should be assessed, the Business Case and plans reviewed to ensure that the project remains viable, and a decision made as to whether to proceed.

Breaking the project into a number of stages enables the extent of senior management control over projects to be varied according to the business priority, risk and complexity involved. Shorter stages offer more control, while longer stages reduce the burden on senior management."

Для принятия решения по дальнейшему финансированию надо:

1. Уточнить план проекта - сколько еще нужно денег, ресурсов, времени для получения результата?
2. Уточнить бизнес-кейс (экономическое обоснование проекта). Имеет ли смысл вкладываться? 

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

1. Обзор стандартов описания жизненного цикла и его практик TechInvestLab.ru Версия 1.0, 30 ноября 2009г.
2. ISO15288 (ГОСТ Р 57102)
3. ГОСТ Р 57193
4. ИСО12207
5. ГОСТ Р 57098
6. Связанный с ними ГОСТ Р ИСО/МЭК 26555-2016 и ИСО15926

Бюджет и освоенный объем

1. Цена контракта состоит из выделенного на проект бюджета (TAB) и прибыли. Спонсор проекта отвечает за его полный бюджет.
2. Бюджет складывается из оговоренной цены контракта (NCC) и оговоренных расходов будущих периодов (AUW), которые будут понесены в будущих ФАЗАХ проекта. NCC+AUW дают базовый бюджет контракта (CBB), который вместе с перерасходами дает одобренный сверхплановый бюджет. OTB - зона ответственности спонсора проекта (executive PRINCE2).
3. OTB разбивается на базовый план проекта по стоимости (часть базового плана по измерению исполнения, PMB, performance management baseline) и управленческий резерв (MR). Обычно руководитель проекта не имеет прямого доступа к управленческому резерву без санкции спонсора проекта.

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

Базовые планы проекта включают в себя, среди прочего:

• базовое расписание;

• базовый план выполнения стоимости;

• базовый план по содержанию.

Часто базовые планы по содержанию, расписанию и стоимости объединяют в базовый план

измерения исполнения, используемый в качестве общего базового плана проекта, с которым может сравниваться общее исполнение. Базовый план измерения исполнения используется для измерения освоенного объема."

4. PMB, в свою очередь, состоит из контрольных счетов (CA = WP + PP), стоимость которых равна стоимости оценки выполнения работ и стоимости самих работ, оценки стоимости работ будущих периодов (SLPP) и нераспределенного бюджета (UB). 

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

 Итоги:

1. Есть стейкхолдеры (роли), представители стейкхолдеров (конкретные люди, исполняющие эту роль), оргместа (сборники ролей с полномочиями и ответственностью) и люди, занимающие должности (оргместа). Стейкхолдеры бывают задействованные и затрагиваемые. Стейкхолдеры учитываются в описании архитектуры.
2. У стейкхолдеров есть интересы, которым отвечают view/модели/системные описания. Если есть view, под него есть стейкхолдер, есть стейкхолдер, под него должен быть view.
3. На стороне заказчика минимум есть 4 стейкхолдера - пользователь, приобретающая сторона, ЛПР и капиталист. Под их интересы нужны свои модели, надо договариваться на старте проекта, какие конкретно. Минимум - как и когда платить (фазы проекта и бюджет), какую функциональность и когда получаем (жизненный цикл проекта, план релизов, дорожная карта), как окупаем инвестиции (экономическое обоснование проекта, бизнес-кейс, бизнес-план, бизнес-модель). 

А теперь еще раз внимательно перечитайте PRINCE2, стало понятнее, почему он такой эффективный и популярный? Вот так-то.