Блог

БЛОГ

«Я — менеджер проекта!». Заинтересованные стороны: заказчик, исполнитель, команда и их требования

Четвертая глава руководства «Я — менеджер проекта!» Сергея Вратенкова. 
Предыдущие главы вы можете найти по ссылкам:

Введение
Первая глава: первая часть, вторая часть
Вторая глава: первая часть, вторая часть, третья часть
Третья глава.

4        Заинтересованные стороны

4.1.1     Участники и требования

Мы очень близки к важному промежуточному результату – построению практичной модели проекта. Мы начали с результатов и добрались до показателей. В последнем варианте модели есть одна непонятка – откуда берутся результаты? Многие проекты получают спецификацию результатов как предварительное условие – в контракте или в уставе. И тогда вопрос закрыт. Но… Есть одно но… Уверен, Вы знаете, что я скажу дальше. Скажу я, что не все так просто, и даже гораздо хуже.

Во первых, не все проекты имеют ясные спецификации. А во вторых, и именно это названо «гораздо хуже» — в нашем мире исполнение спецификаций не означает отсутствия проблем. Проблемы эти называются так: «НЕ удовлетворенность заинтересованных сторон».

Поясню на примере:

Пример: Требования участников проекта

Я – бывший прораб проектов точечной застройки в жилых кварталах Москвы. И имею приличный опыт в этой области.

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

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

Но… Где-то через две-три недели, когда мы уже половину свай для фундамента забили, подъезд к стройке перекрыли аборигены – их было не более десяти. Но стояли насмерть, бросались под колеса грузовиков, одна сумасшедшая мамаша даже своего грудничка кидала. Все бы ничего, может, решили бы проблему, но откуда-то налетело телевидение.

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

Я теперь управдом этой самой свечки. Гнетут тяжелые предчувствия, но я стараюсь не унывать – пишу воспоминания «Идентифицируй требования участников проекта, или…».

Так вот, пример, конечно, сильно утрирован, но утрирован он с благой целью – исполнители должны забыть о соблюдении спецификаций, как единственном оправдании для любого «неожиданного» недовольства!

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

Мы в нашей практичной модели проекта не можем ориентироваться на наличие четких и достаточных спецификаций. Нам нужны более практичные основания. Эти основания – собственно источники спецификаций — заинтересованные стороны проекта и их требования к проекту.

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

Заинтересованные стороны имеют свои ожидания от проекта, которые команда проекта должна выявить и трансформировать в требования к проекту и спецификации. Детально мы обсудим эту тему позже, нам важно расширить наше представление о проекте. До сих пор, вслед за определением проекта в PMBOK, мы считали, что проект – это начинание для производства продукта. С учетом наличия в проекте заинтересованных сторон, мы должны сказать себе, что продукт проекта создается только для одной из заинтересованных сторон – для заказчика. А должен ли проект что-либо произвести для других интересантов? Однозначно должен, иначе они произведут большие проблемы. Получается, что проект – это не только производство продукта для заказчика, это еще и производство продуктов для каждого интересанта. С такой точки зрения заказчик оказываются в общем ряду с другими заинтересованными сторонами. Часто в проектах неочевидно, кто из интересантов «страшнее», и ориентация только на интересы заказчика может оказаться довольно рискованной, как было показано в примере. Мы расширяем определение проекта, включая в него заинтересованные стороны:

Проект – это временное уникальное начинание для удовлетворения интересов заинтересованных сторон

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

Согласно нашей модели, проект инициируется заинтересованными сторонами. Далее команда проекта выявляет требования интересантов и результаты проекта, которые эти требования удовлетворят. Затем определяются работы и ресурсы, необходимые для создания результатов. Далее, исходя из стоимости ресурсов, определяются стоимости работ и всего проекта. Получаем план проекта, который согласуется и утверждается заинтересованными сторонами. Исполнение проекта – это путь в обратном направлении: ресурсы в процессе работ преобразуются в результаты, результаты передаются заинтересованным сторонам. Все довольны, проект завершен!

4.2       Требования участников – старт планирования

Миром правит интерес — ищи интерес!

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

Так зачем нарываться на грабли? Не лучше ли немного поразмыслить и предупредить беду? Так что, давайте займемся тем, что в управлении проектами называют анализом заинтересованных сторон. И чтобы все это не было абстрактным, будем сразу анализировать требования к нашему проекту «Строительство домика».

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

4.2.1     Выявляем требования заказчика проекта «Строительство домика»

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

Заказчиком домика будет семья в составе: муж, жена и обязательно, дети и теща, последние – чисто в методических целях как дополнительные источники неслабых рисков нашего, в общем-то рядового, проекта. Главным будет муж, главным юридически, он подписывает все документы. Но на заметку, где-то на полях, мы себе запишем, что за остальными нужен глаз да глаз – они не только способны радикально влиять на мужа-заказчика, но на поверку любой из них может оказаться реальным заказчиком!

В первую очередь анализируем отношение заказчика к трем основным показателям – сроки, стоимость, качество. Будем считать, что нам достался обычный заказчик с обычными требованиями – максимальное качество при минимальных сроках и стоимости. Такая общая формулировка – слишком общая, с такой формулировкой требований мы прямо напрашиваемся на классическую ситуацию сдачи-приемки: «Мы же договаривались, что эта комнатка будет голубенькой (розовенькой, зелененькой, …) и побольше (поменьше, треугольненькой, …)». И на классический выбор – попытаться снять претензию, переделать за свой счет или вытрясти дополнительные средства из заказчика, или судится из-за комнатки. Если судиться, то — с непредсказуемым результатом. Вернее, с вполне предсказуемым: судьи – тоже люди, а значит, тоже заказчики. Заметьте, время теряется в любом варианте! А время, как говорят классики – деньги.

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

  • — Сроки – 1 мес. (+ 5 дней)
  • — Стоимость – 1 млн. руб. (+ 10%)
  • — Качество – кирпичный дом, 10Х10 м, 2 этажа, детализация в ПСД

Небольшие комментарии.

ПСД – это проектно-сметная документация, в состав обычно входят архитектурный план и смета (просто перечень) расходов на трудозатраты и материалы, в которой прописаны работы и материалы.

По требованиям к качеству мы пока имеем от заказчика самые общие спецификации: «кирпичный дом, 10Х10 м» и важное дополнение: «детализация в ПСД». Это дополнение означает согласие заказчика на дальнейшее уточнение спецификаций в течение проекта, НО в рамках оговоренных сроков и стоимости.

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

4.2.2     Выявляем требования исполнителя проекта «Строительство домика»

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

Для нашего проекта «Строительство домика» исполнителем является организация, в которой тружусь Я — менеджер проекта. Прошу не ассоциировать это «Я» с автором, «Я» — это менеджер проекта, от лица которого ведется повествование. Конечно, повествование веду я, автор, но все равно прошу не ассоциировать, или, хотя бы не везде и не всегда.

Итак, наша задача здесь и сейчас – выявить интересы своей организации как исполнителя проекта «Строительство домика». Не следует думать, что менеджеры проектов прекрасно знают эти самые интересы. Тут следует не думать, а выявлять! Хотя думать все равно желательно. Вопрос не столько в правильности зафиксированных интересов, сколько в ответственности за указанные интересы. Это интересы бизнеса организации, а не интересы проекта. И формулировать бизнес-требования к проекту могут только руководители бизнеса, которые находятся вне проекта и выше команды проекта в организационной иерархии. Менеджер проекта обращается к Куратору проекта и другим руководителям с просьбой определить требования к проекту. Давайте будем считать, что для нашей организации этот проект является довольно рядовым и где-то даже рутинным. В конце концов домик – это не дворец! То есть это типичный бизнес-проект и главное требование – прибыль. Однако нашей организации небезразлично хорошее отношение клиента и добавляется еще одно требование – удовлетворенность заказчика. Требования по срокам и стоимости обычные – максимальный минимум! Однозначно.

Фиксируем требования исполнителя:

  • — Сроки – согласно договору, премия команде за сокращение
  • — Себестоимость – 50% договорной цены, премия команде за сокращение
  • — Качество – согласно договору, премия команде за положительный отзыв заказчика

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

Переходим к анализу требований исполнителя.

4.2.3     Выявляем требования команды проекта «Строительство домика»

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

Может показаться, и в нашей практике такое мнение распространено, что команда – это наименее значимый участник проекта и вообще, это чисто головная боль менеджера проекта. Такое мнение скорее не верно, чем верно, хуже того, такое отношение для проекта гораздо опаснее, чем для постоянной деятельности. Опаснее из-за временности проекта и ограниченными возможностями для маневра. Для менеджера проекта команда – это его основной ресурс и поддержание исполнителей в прекрасном состоянии  — это его основная гарантия успеха. Для менеджера проекта все заинтересованные стороны равны, команда – не исключение.

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

Фиксируем требования команды проекта:

  • — Сроки – согласно договору, но с достаточными резервами
  • — Оплата труда – стандартная система мотивации + премии за сокращение сроков и стоимости, за положительный отзыв заказчика
  • — Качество – согласно договору, но достижимое в рамках сроков и оплаты труда

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

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

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

4.2.4     Реестр участников – паспорт заинтересованных сторон проект

На этом первый шаг планирования проекта завершается. Его результаты сводим в одну таблицу, которая называется Реестр участников. Для нашего проекта «Строительство домика» она выглядит так:

Сверх важно!

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

4.2.5     Всем сестрам – по серьгам, каждому участнику – по продукту!

На предыдущем шаге планирования мы выявили требования участников к проекту. Теперь нашей задачей является определение таких продуктов и результатов, которые смогут удовлетворить требования каждого участника. Основная задача – удовлетворить всех из одного ограниченного источника – непростая задача. Дать кому-то больше всегда означает – дать другим меньше. Причем необходим не просто компромисс, а такой компромисс, который устраивает всех. Ведь любая, даже небольшая поначалу неудовлетворенность любого участника может легко перерасти в большие проблемы. На первый взгляд может показаться, что задача неразрешима. Однако она решается на практике, доказательством тому – множество успешных проектов, причем успешных по мнению всех заинтересованных сторон. Как она решается? – Просто! Любой менеджер-профессионал знает приемы разрешения неразрешимых задач.  Но это широкая и самостоятельная тема, мы выделим для нее отдельную главу и обсудим ее позже. А пока только констатируем:

Важно!

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

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

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

Практики могут теперь переходить к следующему шагу планирования – «Содержание проекта – структура работ и операции». Теоретики-почемучки могут продолжить чтение этой главы. Далее – специфика и основные особенности продуктов и результатов проекта, оглядка на которые не помешает.

[ratings id=»»]

Телеграм канал