Статья предоставлена редакцией информационно-аналитического журнала "Управление Проектами" в рамках совместного проекта с Финансовой академией “Актив”.
Современные методы и средства проектного управления, статьи по развитию навыков и компетенций в области управления проектами, программами и портфелями проектов доступны при приобретении выпуска журнала или при полугодовой и годовой подписке.
Ни для кого не секрет, что в глазах руководства любой Организации проект выглядит приблизительно так: хотим, чтобы проект был реализован в максимально сжатые сроки (желательно вчера); за счет своих средств и ресурсов, а если за счет привлеченных — то чтобы еще и в плюсе остались; и чтобы в результате это была такая «конфетка», которую было не стыдно с выгодой продать клиенту. А лучше, если еще в ходе проекта клиенты будут стоять в очереди на коленях с плакатами в руках «Хотим! Хотим!». Шутка-шуткой, но если вы поставите себя на место руководителя или собственника Организации, то поймете, что это желание не такое уж смешное и идиотское.
Представьте, что вы за свои деньги, или еще хуже, в кредит, строите себе дачу. У вас есть наемный бригадир с кучей строителей. Ваше естественное желание построить подешевле, побыстрее, но качественно, может быть несопоставимо с качеством «проектной команды» и интересами бригадира: хорошо, пока есть оплачиваемая работа и материал, который можно пустить налево. Теперь представьте, что вы параллельно строите не одну такую, а десяток дач из разного материала, по разным чертежам, в разных местах, разного класса и у десяти разных бригадиров с разным опытом. Где-то прорвались грунтовые воды, где-то осел грунт, не подвезли вовремя кирпич и бетон, бригада и техника простаивает, деньги на эту стройку почти закончились. Там — бригадир ушел в отпуск, тут обвал стены, здесь забыли, что в дизайне предусмотрены двери, окна и крыша, в другом месте — экскаватор повредил кабель подстанции, обесточив соседнюю стройку, в этом — на бумаге должны были уже подводить дом под крышу, а на деле еще даже колышки для разметки котлована не вбили…
Так вот в глазах руководителя или собственника Организации все проекты выглядят примерно так же. Осознали масштаб катастрофы? Задача PMO[1] помочь ему контролировать ситуацию, и если не получается «продать с выгодой», то спасти хоть какую-то часть вложенных средств.
Заводя разговор об объективной оценке проектного управления, предвижу тысячу оппонентов с возражениями вида: «ваш подход некорректен», «все совсем не так», «на практике так не получится», «в MS Project / PM BOK[2] такого нет», «это совсем разные вещи», «академик Петров считает иначе», «а у нас Scrum[3]», «почему не воспользоваться P3M[4]?», «нам удобнее по освоенному объему» и т.д. Поэтому хочу сразу предупредить, что эта статья не претендует на звание научно-теоретической, всеохватывающей, универсальной и не сможет служить украшением учебника по управлению проектами. Это практично-популярный аналог описания собственного подхода, который почти идеально применим к моей ситуации, и может быть не применим к вашей.
Итак, уточним, что именно мною понимается под терминами «объективная оценка» и «оценка эффективности». По моему мнению, объективная оценка — это оценка, получаемая из нескольких независимых источников, рассматривающая объект оценки в объеме и динамике. А оценка эффективности – это анализ достижения субъектом оценки поставленных целей, выполняемых задач относительно затрачиваемых ресурсов. Под ресурсами могут пониматься время, деньги, люди, ИТ-средства, механизмы, сырье, материалы, полуфабрикаты и прочее.
Теперь, когда с терминами определились, можно перейти к сути вопроса.
Ключевой вопрос: «Зачем?»
Следующий шаг — самый важный. Нужно ответить для себя и для руководства — для чего вы проводите оценку? Какое решение вы или ваш руководитель (собственник или генеральный директор) должен принять на основе представляемой оценки? Вы хотите просто похвастаться? Наказать провинившихся? Обратить внимание на проблемы и риски? Привлечь административные и лидерские ресурсы? Попросить дополнительного финансирования, выделения ресурсов?
Я заостряю на этом внимание потому, что очень даже может быть, что оценка в силу целого ряда объективных факторов может сложиться не в пользу проектного управления. Это особенно часто бывает в Организациях с плохо развитой проектной культурой, с низкой поддержкой или заинтересованностью руководства, с дефицитом ресурсов на проекты. В итоге руководство может разочароваться в проектах и перевести работу в повседневную операционную деятельность. Но мы же с вами понимаем преимущества проектной деятельности. И дело не только и не столько в итоговых бонусах. Шутка.
В моей практике был такой случай – в одной крупной российской организации пять раз перезапускали управление проектами, потому что люди, предположительно управлявшие этим чудом, никак не могли донести до руководства какие решения оно должно принимать. Далее проекты переводили в «текучку». Там они буксовали и умирали бесславной смертью. Потом вновь рождались в виде проектов, но уже с новыми командами. И так по кругу в течение почти десятка лет. Поэтому проведенная оценка должна подкрепляться выводами и вашими предложениями, что следует предпринять дальше. А еще ответ на вопрос «зачем?» поможет решить, что включать в итоговый отчет, а что оставить за кадром.
Вопрос 2: «Что оценивать?»
Далее нужно определиться, какие требования предъявляются к проектному управлению в Организации.
Первое – обычно это соответствие решаемых проектным управлением задач общим целям Организации и руководства. Вопрос: если Организация выполняет непрофильные проекты, например ИТ-компания взялась за строительный подряд, то отвечает это или не отвечает целям Организации и руководства? Считаете, что не отвечает? Нереальный случай? А почему нет? Может быть, руководство Организации решило диверсифицировать бизнес, и с помощью штатных, а может быть силами привлеченных менеджеров проектов, используя их опыт управления, а так же текущие ИТ-средства, возможно даже собственной разработки, выйти на рынок проектного консалтинга в строительстве. Таким образом, Организация получит дополнительный центр прибыли. Вопрос деликатный и на него может ответить только руководитель, знакомый с ее стратегией.
Второе – эффективность решения поставленных задач и постоянное улучшение, чтобы минимизировать ресурсы, усилия и сроки внедрения проектов, а так же максимизировать отдачу (в виде объема, качества продуктов проекта, дополнительной прибыли, привлеченных клиентов и тп).
Рисунок 1. Пример диаграммы оценки текущего состояния управления проектами
Проблемы прикладной оценки
Каждый, кто собрался в своей Организации провести оценку эффективности проектного управления с какой-то долей объективности, сталкивается с рядом требующих решения проблем. Например, с такими:
Проблема 1. Определение ключевых факторов, функций, компетенций, которые требуется измерять.
В каждой уважающей себя Организации, где внедрено проектное управление, существует положение о проектном управлении или иной документ, который регламентирует проектную работу. Если он составлен грамотно, то обычно упомянутые выше функции в этом документе указываются. Для упрощения можно взять всем известные 9 областей знаний PM BOK. Можно воспользоваться ими, можно разложить на BSC[5] или выбрать более подходящие другие. Я выбрал свои и приоритезировал по значимости для PMO, и оказываемому влиянию на итоговый результат проекта следующие факторы:
- Расписание;
- Бюджет;
- Ресурсы;
- Управление рисками;
- Управление изменениями;
- Управление процессами УП;
- Управление документацией.
На их основе (см. Рисунок 1) можно демонстрировать как общую картину, так и проводить индивидуальную оценку конкретного проекта. Можно задать ожидаемые или целевые параметры и сравнивать с ними текущую ситуацию, искать разрывы и проводить оценку причин отклонений.
Тут хочется сделать предостережение. Первое — не пытайтесь измерить все и вся. Много показателей не значит хорошо, хоть мы и говорим с вами об объективности, плохо, когда руководство или собственник, глядя в ваш отчет, видит «фигу».
Второе – не забывайте о простоте. Информация должна быть доступна и понятна. Поверьте, у собственников и руководителей голова в большей степени занята продажами и сокращением издержек, чем проектами. Картина маслом: подаете вы отчет «товарищу первому». «И что?» — спросит он и будет прав. Как так? В отчете же все есть, скажете вы. И вы правы, но для руководителя этот отчет будет не понятен без предварительного изучения. А время на принятие решения в современных организациях не более 5 минут или еще меньше. Есть такое выражение «презентация в лифте». Словно вы едете в лифте вместе с генеральным с одного этажа на другой, что составляет всего около 30 секунд!!! Если за это время вам не удалось донести то, что хотелось и добиться нужного решения, то можно смело записываться на курсы «кройки и шитья», точнее эффективных презентаций. Из практического опыта — в случае вашего провала, шансы на принятие желаемого вами решения в следующий удобный момент меньше вполовину.
Мой друг работал в одной организации, где к краткому отчету о проектах полагалась: краткая справка по истории вопроса, подшитые копии решений трех последних совещаний и копия реестра решений. Мне самому на другом месте работы как-то выпал шанс запросто пообедать с генеральным («запросто» не потому, что он не либерал и затворник, просто очень занятой человек). Помимо других тем всего за 15 минут обсудили и решили все проблемы, вынесения которых на совещание я добивался почти два месяца.
Еще один совет. Всегда пытайтесь «влезть в шкуру» собственника. Как бы вы отреагировали на собственный отчет? Чего бы он ждал от него?
Статистика проектов, шт | Январь | февраль | … | ноябрь | декабрь | Изменение |
А | 1 | 2 | 11 | 12 | 13 | |
Текущие | ||||||
Открыто | ||||||
Запущено | ||||||
Завершено | ||||||
Закрыто | ||||||
Остановлено | ||||||
Отчитались МП | ||||||
Средневзвешенное по проектам (текущие минус открытые и закрытые) | ||||||
KPI (проектная активность: отчитавшиеся МП к текущим), % |
Таблица 1. Пример статистики по проектам и KPI на ее основе
Проблема 2. Получение разноплановых взглядов
Обратная связь должна поступать из разных источников. Она должна отвечать соответствуют ли решаемые проектным управлением задачи (в разрезе выделенных факторов) общим целям Организации и руководства, а так же эффективно ли их решение. Первая сторона обеспечивает взгляд изнутри – менеджеры проектов, менеджеры программ, Кураторы. Не всегда их оценки будут совпадать, и это само по себе хорошо. Вторая – взгляд со стороны: специалисты, сопровождающие проект (офис проектного управления). Для объективности нужен взгляд со стороны Заказчика (оценим его удовлетворенность) и со стороны Спонсора. Это могут быть коммерческий отдел или финансы. Они способны помочь посчитать NPV, PP, IRR[6] сделать анализ прибыльности продукта.
Такую сводную информацию можно получить, если подготовить опросник в виде чек-листа для простоты оценки. Хочу описать другой пример из собственного опыта, как еще можно проводить подобную оценку. Во время общего совещания участников проектной команды, я попросил разместить по три трехцветных маркера-наклейки в описанных выше областях. Каждый мог поставить в одну область не более одного маркера, и мог не воспользоваться каким-либо цветом по желанию. Плюсы: хорошее вовлечение участников, результаты появляются моментально, наглядно видны проблемные зоны, эти проблемы видны всем, что позволяет немедленно поднять вопрос. Есть и минусы, но о них отдельно.
Проблема 3. Разработка метрик (KPI[7])
Необходимо иметь ряд простых, но понятных метрик для проведения такой оценки. Для каждой из выбранных факторов как минимум один показатель. В таблице 1 приведен пример для расчета одного из KPI. Можно использовать показатель, основанный на прохождении ключевых вех. Тут могут быть вариации самого разного вида и форм. Их ограничивает только фантазия автора – суммарное опоздание, средне взвешенное выполнение плана, % соблюдения мастер-плана и т.д. Раз мы говорим об эффективности, то должны быть предусмотрены нормативы и цели для сравнения, а лучше верхний и нижний пороги. Потребуется какое-то время для оценки статистики. Следующим логичным шагом для повышения эффективности будет закручивание гаек – установки более жестких нормативов;
Проблема 4. Регулярность мониторинга
Важно определить – будет ли оценка системной и регулярной? Или будет носить разовый характер по запросу? Очевидно, это повлияет на ресурсы и инструменты для ее проведения. Для регулярных оценок методики должны быть максимально простыми, а метрики автоматизированными, иметь возможность drill-down[8] и оценку показателей в динамике. Основная часть работы должна быть сосредоточена в коммуникациях с менеджерами проектов и на анализе полученных результатов. При разовой оценке можно составить углубленный анализ, выделив какие-то ключевые области, важные для руководства – процесс работы с заказчиком, закупки в проектах, управления рисками и т.п. Можно уделить больше внимания сопоставлению разных данных, сравнению проектов друг с другом (например, если в портфеле есть похожие проекты или у вас есть выполненный эталонный проект);
Проблема 5. Формат, в котором должна выводиться оценка.
Еще раз воспользуюсь своим опытом: делайте два — расширенный и сокращенный, который можно быстро сформировать из первого. Сокращенный должен занимать 1-2 слайда MS PowerPoint. Он просто необходим для показа на крупных совещаниях, когда вам выделяется не более 5 минут на весь доклад. Так же сокращенный вариант — незаменимая вещь в качестве приложения к регулярному отчету о работе PMO или для рассылок высшему руководству. Расширенный формат – необходим для совещаний с Кураторами, Спонсорами, менеджерами программ. Так же по формату нужно упомянуть, что не плохо бы формировать его в удобном ПО и без проблем с дополнительным форматированием выводить в опрятном виде на печать. В моей практике уже не раз было так, что «товарищ первый», проходя мимо по дороге в заграничную командировку к другому своему бизнесу, просил распечатать с собой в дорогу, при том, что у человека есть все мыслимые и немыслимые современные ИТ-девайсы.
Проблема 6. Что делать дальше?
Вот вы потратили время на подготовку оценки. Что делать дальше? Должен быть подготовлен максимально конкретный план действий на 1-3 месяца. Что в него включать уже зависит от вас, но как в любом плане там должны быть указаны сроки исполнения, ответственные за исполнение. Я еще вписываю какой ожидается результат. Если необходим документ, то вписываю, какой. Если задача «обеспечить мониторинг», то пишем как, кто, какие показатели, системы будут использоваться. Обеспечение, если требуется бюджет, ресурсы, иная помощь или поддержка. Еще один полезный пункт плана – кто проконтролирует исполнение?
А как же ROI[9]?
Справедливый вопрос. Не каждая Организация сможет на него ответить. У меня есть знакомый, работающий в одной компании, которая занимается исключительно проектной работой, обслуживая энергетический сектор. Там этот показатель очень популярен и его вставляют, где надо и где не надо. В знакомой ИТ-компании, занимающейся заказной разработкой, все меряют одним показателем – чистая прибыль с проекта.
Если мы говорим про оценку эффективности, то этот показатель может быть очень полезен. Но я был бы осторожен. Сугубо мое мнение такое, что для его применения нужно иметь хорошую базу[10] для расчета реальных инвестиций и реальной отдачи, чтобы все было по-честному. Иначе «кривым» подсчетом можно «подрубить» хороший проект. Еще один момент – кто и как считает. Cui prodest?[11] Не исключена личная заинтересованность в завышении и занижении показателя, чтобы выгородить себя или очернить оппонента. Это относится ко всем KPI, но, если речь заходит о коммерческих организациях, к этому в большей степени.
В нашей практике (а у нас производственная компания) мы ROI используем очень ограниченно, но не потому, что он не нравится лично мне или руководству. Просто у нас есть море других показателей, которыми можно измерить то же самое, только несколько иначе.
Подводя итоги
Я рассмотрел только одну часть видимой верхушки айсберга под названием «оценка проектной деятельности», исходя из собственного опыта применения лучших мировых практик. Не даю никаких ссылок на источники и литературу, так как при подготовке материала ничем подобным не пользовался. Какие-то находки сделал сам, какие-то подсмотрел у друзей, какие-то были спущены свыше. Вне рамок этого обзора остались система и организация, аудиты, оценка менеджеров проектов, оценка проектного риска, всевозможные инструменты, автоматизация и применение КИСУП для подобной оценки, учет и накопление данных, и еще много чего. Мне даже почти полностью удалось избежать перечисления сотен вариантов KPI.
[1] Project Management Office – офиспроектногоуправления
[2] Project Management Body of Knowledge – стандарт проектного управления, разработанный PMI
[3] Scrum – одна из популярных современных методик управления проектами, преимущественно ИТ.
[4] Project Management Maturity Model- методика оценки зрелости проектного управления в организации
[5] Balanced Score Card – карта сбалансированных показателей. Методика управления организацией, основанная на выделении, установлении взаимосвязи и балансировки стратегически значимых для управления Организацией целей и показателей, которые образуют стратегическую карту в 4 плоскостях: финансы, клиенты, процессы и развитие.
[6] Net Present Value (чистый приведенный доход), Payback Period (срок окупаемости), Internal Rate of Return (внутренняя норма доходности) – финансовые показатели эффективности проекта.
[7] Key performance indicator – ключевой показатель эффективности
[8] Drill-down (буквально с англ. «углубляться») – термин, применяющийся в аналитических системах для прослеживания связей между результатом и исходными данными.
[9] Return of investment – показатель возврата инвестиций. Одна из формул для подсчета: (доход от инвестиций – инвестиции)/инвестиции
[10] В это понятие я вкладываю не только ИТ-систему и базу данных, но и методику, логику, компетенцию и практику.
[11] Одно из крылатых латинских выражений: «Кому выгодно?»
Зарегистрируйтесь и пройдите 4 пробных урока курса бесплатно, чтобы оценить, насколько он интересен вашей карьере!