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

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

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

Слайд об Оксане Клименко

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

Понятие «проект»

Слайд с определением понятия "проект"

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

Соответственно, каждый волен сам выбирать критерии, по которым деятельность будет делиться на «проектную» и «операционную» — о том, что это необходимо, думаю, говорить не стоит. Здесь большое поле для творчества (это все реальные схемы, которые применяются в компаниях-участниках семинара):

  • Длительность итерации и количество трудозатрат до получения результата
  • Наличие собственного бюджета подразделения на данные работы (отсутствие необходимости искать внутреннего спонсора)
  • Наличие доходной части для компании в результатах проекта (например, выход на новый рынок – проект, так как будет новая доходная часть, которая покроет затраты на проект, а модернизация ИТ-системы под требования закона по ОСАГО – не проект, так как собственной доходной части не создается)

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

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

Слайд с шуткой о проектном управлении Слайд о профессиональном проектном управлении

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

  • Количество проектов в компании (или в одном бизнес-подразделении) больше 5
  • Когда для реализации большинства проектов нужны ресурсы более, чем одного бизнес-подразделения.

В этих случаях как раз будет заметна экономия времени и средств на проектах при формальном увеличении затратной части на оргструктуру.

Типы организационных структур, метод «А вот возьму, и сделаю!»

Слайд с типами оргструктур

Слайд с функциональной структурой Слайд с проектной структурой

Слайд с матричной структурой

Ничего нового в таком делении нет, добавлено категория «смешанная», обычно, это пересечение функциональной и проектной или функциональной и матричной структуры. Интересным для меня было обсуждение вопроса «как отличить «де-юро» от «да-факто». Ситуации, когда есть формально выделенное подразделение, состоящее из формальных руководителей проектов не так уж редка. Но при этом, де-факто руководители проектов являются администраторами проектов, а реальным управлением занимается руководитель подразделения, чьи ресурсы (большинство ресурсов или ресурсы на самую важную часть проекта) задействованы. Поучается, что по формальным признакам компания имеет матричную структуру, а по фактическим – функциональную. Опасность такой ошибки состоит в том, что результатом проекта никто по факту не управляет: менеджер проекта, не имея реальной власти, придумывает оправдания просрочкам, считая, что его задача «спрашивать у функционального руководителя «ну, как дела, когда сделаете?», а функциональный руководитель управляет только интересными ему (на основании целей его подразделения) задачами. Всем знаком пример проекта, когда нужно разработать программу, внедрить ее, обучить пользователей и обеспечить приоритетную поддержку в период опытно-промышленной эксплуатации. На проект назначается менеджер проекта, но как только начинается этап разработки, то власть переходит к руководителю отдела разработки – он определяет последовательность работ, ресурсы, график выхода релизов и т.д. Но как только разработка закончена, то проект подвисает – менеджер проекта по инерции говорит: «Ну, давайте внедрять», а руководитель разработки говорит: «Не, это не мое уже, мы разработали, и хватит, иди в эксплуатацию». Руководитель эксплуатации, обычно, замотивирован на быстрое решение инцидентов и закрытие заявок в срок. Для него выделение ресурсов на внедрение нового программного продукта – лишний головняк, который никак не будет отмечен – KPI заточен под закрытие заявок по инцидентам. Менеджер не имеет реальной власти – распоряжаться ресурсами он не может, получается коллапс. Если четко понимать структуру компании, то можно разрабатывать регламенты процессов на основании реальности – например, построить KPI подразделения эксплуатации, чтобы проектами было заниматься так же выгодно, а не тешить себя мыслью, что «менеджер проекта всем управляет». Описанная выше ситуация опасна так же тем, что проблема на верхний уровень «выплывает» только тогда, когда критическая точка для маневра уже пройдена. По сути, топ-менеджер может либо согласиться с увеличением сроков и бюджета, либо согласиться с уменьшением функционала, либо «с гиканьем и улюлюканьем» заставить всех работать по 24 часа для исправления ошибок.

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

Механизмы управления в матричной структуре

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

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

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

Сначала слайд из презентации, а далее – мое переложение этой же инфографики.

Слайд с системной моделью управлния проектами РАУП

Слайд с системной моделью управлния проектами 

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

Каждое предприятие самостоятельно определяет объекты управления, обязательных стейкхолдеров, горизонты управления, функциональные области, критерии успеха и управляющие воздействия. Пакет документов (или документ – зависит от объема), который содержит данные определения, называется «Положение о системе проектного управления в организации». В нем рекомендуется иметь следующую информацию:

  • Цели проектного управления в компании (для компании, у которой основной бизнес завязан на реализацию проектов цели управления будут сильно отличаться от компании, в которой проекты являются инструментом итерационного развития)
  • Участники проектного управления (должности или роли, которые заинтересованы в качественной реализации проектов на предприятии)
  • Регламенты по фазам жизненного цикла, по стадиям процесса управления для каждой фазы жизненного цикла, по функциональным областям для каждой стадии процесса управления
  • Инструкции – должностная, ролевая (для роли обязательно должно быть указано время действия роли относительно рабочего дня – все время и частичная занятость), рабочая (мы называем ее методикой).

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

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

У нас в России с сертификацией все плохо. Причем, даже сертифицированные специалисты не могут в полной мере реализовать собственный потенциал, так как уровень проектной зрелости наших компаний очень невысок: 6 крупных Российских компаний, которые оценивались по методике IPMA Delta (современная методика оценки организационно-технологической зрелости в области проектов, о ней ниже), имеют оценку 2 из 5. Это значит, что в компании имеет смысл иметь набор обучающих материалов и курсов, которые должны проходить новые сотрудники. На собеседовании стоит задавать вопросы на понимание базовых для компании принципов, а по окончании обучения проводить внутреннее тестирование для оценки освоенного материала.

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

Далее мы разбирали конкретные инструменты, по которым у участников семинара были вопросы или заинтересованность. Я хочу рассказать о двух инструментах.

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

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

Стейкхолдеры – участники и заинтересованные стороны проекта. Они либо влияют на проект, либо испытывают влияние на себе.

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

Слайд по управлению стейкхолдерами

Для наглядного отображения используется следующая таблица:

Стейкхолдер

Интересы, цели в проекте

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

Инвестор Вася

Продажа результата проекта

Финансирование без нарушения графика платежей

Защита проекта перед чиновниками

Чиновник Петя

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

Освещение проектной деятельности в СМИ

Лоббирование интересов проекта в Думе

Руководитель отдела Семен

Получение нового опыта

Целевое использование людских ресурсов

Высокое количество реализованных инновационных идей

Высокое качество готового продукта

Бухгалтерия

Повышение производительности труда

Увеличение прозрачности бухгалтерии

Освоение новых процессов работы и нового программного продукта

Для управления стейкхолдерами строят матрицу влияния\отношения.

Матрица влияния\отношения стейкхолеров

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

Инструмент для управления коммуникациями

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

Слайд по разработке плана коммуникаций проекта

Вот как может выглядеть матрица коммуникаций:

Отправитель

Получатель

Средство (формат) коммуникации

Частота

Способ (технология) коммуникации

Ожидаемый результат

Руководитель проекта

Инвестор

Отчет «Сделано-планируется сделать»

Один раз в месяц

Электронная почта

Утверждение инвестором достигнутого прогресса

Согласование мероприятий на следующий период

Согласование корректирующих мер

Руководитель проекта

Проектная команда

Повестка совещания

Один раз в неделю

Собрание

Контроль исполнения поставленных задач за прошлые периоды

Принятие решений по темам, заявленным на совещание

Инвестор

Руководитель проекта

Карта стратегических целей проекта

Календарный план проекта

Один раз в квартал

Совещание

Утверждение инвестором достигнутого прогресса за период

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

Разработка корректирующих мер при необходимости

Оценка соответствия стратегических целей произошедшим изменениям внешней среды

Проектная команда

Стейкхолдеры, с уровнем влияния «средний» и выше и отношением «нейтральное» или ниже

Презентация о достижениях за период

Опрос общественного мнения после презентации

Один раз в месяц

Общее собрание

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

Формирование отношения к проекту не ниже «нейтрального».

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

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

Управление рисками

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

  • Снижение (увеличение) вероятности наступления риска
  • Снижение (увеличение) последствий наступления риска

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

Характеристика риска "Неопределенность"

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

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

Матрица ранжирования влияния\вероятности для риска

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

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

Влияние

Очень низкое

Низкое

Среднее

Высокое

Очень высокое

Численная оценка

0,1

0,2

0,3

0,4

0,8

Стоимость

Незначительное увеличение (или в пределах ответственности РП)

Увеличение менее 5%

Увеличение от 5 до 10% (или в зоне ответственности инвестора)

Увеличение от 10 до 20%

Увеличение более 20%

Сроки

Незначительное увеличение (или в пределах ответственности РП)

Увеличение менее 5%

Увеличение от 5 до 10% (или в зоне ответственности заказчика)

Увеличение от 10 до 20%

Увеличение более 20%

Качество

Изменения незаметны (или время непрерывного функционирования не снизится более чем на 0,05%)

Незначительные изменения

Значительные изменения (или изменения, заметные заказчику)

Неприемлемое изменение (или увеличение стоимости сопровождения системы более, чем на 20%)

Достижение конечных результатов невозможно

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

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

Рисковый план

Задачи по снижению (увеличению) вероятности наступления риска заносятся в основной проектный план и участвуют в планировании (определении приоритетов, последовательностей и выравнивании ресурсов) на общих основаниях. А вот с задачами, направленными на снижение или увеличение последствий риска сложнее: с одной стороны, они не должны входить в план работ по проекту, так как будут выполнены только при выполнении определенных условий (не должны влиять на бюджет и ресурсы проекта). А с другой стороны, нужен ответ на вопрос «что если?» — и без включения их в основной план не обойтись. Я рекомендую делать отдельные планы на каждый риск, который требует такого детального планирования. Тогда можно оценить общую стоимость данных мероприятий, легко включить в общий план для моделирования ситуации «что если?» и так же легко исключить после.

Оценка уровня зрелости компании по методологии IPMA Delta

Слайд с описанием методологии IPMA Delta

Слайд с целями и оценками IPMA Delta

Слайд с уровнями по методологии IPMA Delta

Меня в этой теме больше всего интересовал сам процесс оценки и конкретный вопрос «как отличить «де-факто» от «де-юро». Например, если есть регламент инициации проект, подписанный генеральным директором, но нет ни одного проекта (или их количество относительно мало), который бы инициировался в соответствии с данным регламентом, то можно ли говорить о присвоении более высокого уровня по формальному признаку? Ответ, естественно, «ни в коем случае», а для того, чтобы исключить такие коллизии используют следующие инструменты:

  • Опрос сотрудников разных уровней по должностной иерархии
  • Очные встречи с экспертами, проводящими оценку
  • Анализ фактических процессов на соответствие регламентам и приказам

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

Краткое резюме

  • под понятие «проект» можно подвести любую деятельность, критерии деления на «проект»-«не проект» (операционная деятельность) зависят от потребностей каждой компании
  • выделенный проектный офис имеет смысл только тогда, когда стоимость неудач в проектах превышает стоимость содержания проектного офиса;
  • нужно очень точно определять организационную структуру предприятия, чтобы реально оценивать эффективность проектной деятельности (каждая структура имеет свои плюсы и минусы; в функциональной структуре иногда проще работы по проекту превратить в должностную инструкцию для подразделения);
  • для определения реальной ответственности проектных ролей, а так же для оценки структуры предприятия «де-факто» имеет смысл применять метод «А вот возьму, и сделаю!», основанный на оценке тех действий, которые сотрудник может сделать без формального согласования;
  • для компаний матричной и проектной структур имеет смысл использовать системную модель проектного управления и последовательно регламентировать области системы в «Положении о системе проектного управления в организации»
  • управлять ожиданиями или влиянием на проект удобно с помощью таблицы стейкхолдеров и матрицы влияния\отношения для стейкхолдеров;
  • управлять коммуникациями в проекте удобно с помощью матрицы коммуникаций;
  • риск может иметь не только отрицательное воздействие на проект, но и положительное; «плохие» риски надо снижать, «хорошие» — повышать;
  • управление рисками должно быть рентабельным, для этого ограничивают область управления рисками на основе полноты информации по риску, ранжируют с помощью матрицы влияния\вероятности
  • рисковый план удобно пересекать с рабочим планом проекта, закладывая работы по предотвращению (увеличению) вероятности риска в сам план, а мероприятия по снижению воздействия риска при наступлении – в отдельный план
  • при оценке зрелости компании сам процесс оценки важнее, чем формализованный результат по окончании, оценка не должна проводиться приказом «назначить уровень такой-то» сверху, а должна задействовать по возможности большее количество сотрудников.

Добавить комментарий