Перво-наперво необходимо максимально четко сформулировать цели проекта. Желательно, чтобы они были сформулированы по критерию SMART 1 . По опыту, это далеко не так просто. Помню, как у меня на мастер-классе 2 команды из очень крупной энергетической компании формулировали цели своих проектов, которые на тот момент уже были в полном разгаре. После полутора часов споров им наконец-то удалось более-менее четко обозначить цели-до этого в компании было очень размытое понимание, что же именно надо сделать.
Но часто этого недостаточно. Поэтому к цели добавляют описание критериев, по которым в конце будут оценивать проект. Их называют критерии успеха и неудачи проекта. Очень важно определить их на начальной стадии («договориться на берегу»), т.к. это позволит в дальнейшем избежать множества конфликтов, связанных с оценкой его результатов.
Базовые критерии применимы к любым проектам, дополнительные надо всегда выявлять отдельно.
Если не задать критерии, нередко происходят казусы. Так при безграмотном внедрении новой системы мотивации сотрудники не только не начинают лучше
1 См. п. 2.4 «Цели»
работать, но и увольняются. Вначале проекта забыли важный критерий: сохранить ключевой персонал.
Хорошо, если цель проекта формулируется одной фразой и уточняется рядом
критериев.
ПРИМЕР 58. Фёдор Халиулин, руководитель проектно-строительной компании «ГЛАСАРД»: «В коммерческих организациях и большинство проектов являются коммерческими. То есть один из первых критериев успешности - прибыль. Это настолько всем понятно, что иногда этот критерий даже не вносят формально в список. Если допустить такую ошибку в проекте с большим числом участников команды проекта, то может оказаться, что раз прибыль не формализована, то и формальной процедуры контроля прибыльности проекта тоже нет. Руководитель проекта в таком случае останется без оперативного доступа к важней информации».
Пример. К 1 февраля 2011 года открыть и запустить на полную мощность торгово-развлекательный комплекс со следующими параметрами:
- общая сумма инвестиций:... евро;
- расположение: на пересечении крупных автострад в пределах МКАД;
- наличие удобных подъездных путей и парковок на... машино-мест;
- общая площадь: от... кв. м;
-100% сдача торговых площадей в аренду по цене.../кв. мили выше;
- эксплуатационные затраты не более.. ./кв. м;
- количество персонала в штате - не более... человек и т.д.
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 43
Выберите проект, на примере которого вы будете изучать материал
Этой главы.
Проект может быть как реальным, так и выдуманным. Важно, чтобы он был интересен вам и участникам вашей команды. Также вам должна быть понятна его предметная область: либо вы в ней профессионал, либо на основе здравого смысла.
По опыту, хорошо, если это будет типовой проект, который вы выполняете для своих внешних клиентов (конечно, если ваш бизнес состоит из проектов, например, создание сайтов). Или же это может быть инвестиционный проект по созданию нового актива для вашего бизнеса. Или - организационный, такой как внедрение информационной системы. От того, на каком примере вы будете прорабатывать материал данной главы, зависит та польза, которую вы получите. Сформулируйте цели выбранного проекта по критерию SMART и опишите критерии успеха и неудачи.
ОТБОР ПРОЕКТОВ
Ресурсы любой организации ограничены, и всегда стоит выбор, куда их направить: на какой из нынешних или новых проектов, в какое подразделение и т.д. В крупной компании желательно, чтобы применялась официальная процедура отбора проектов, проходящая, к примеру, раз в год на Проектном комитете с корректировкой раз в полгода или в квартал. В мелкой фирме все может быть проще, однако желательно несколько раз в год проводить совещания, посвященные текущим и перспективным проектам.
При отборе проектов учитывают самые разные факторы, например:
Стратегическая важность проекта для компании;
Финансовые показатели проекта (прибыльность, срок окупаемости т.д.) 1 ;
Ограничения:
~ временные;
~ потребность в ресурсах (финансовых, человеческих, технических и пр);
~ технологические;
~ административные;
Уровень рисков;
Стейкхолдеры проекта и их интересы. Для проекта критически важно сделать такой анализ. Например, заинтересованность в проекте собственников или топ-менеджеров компании может перевешивать все остальные факторы. В этом случае, увы, решение о запуске проекта часто принимается волевым путем, без обоснования и расчетов;
Предположения и допущения. Мы часто что-то делаем, основываясь на предположениях, порой не осознаваемых. Долгое время большинство компаний планировали будущее, исходя из того, что благосостояние клиентов будет неуклонно расти. Кризис подкрался незаметно...
При отборе проектов желательно выписать ключевые предположения, исходя из которых вы считаете, что он будет успешным.
ПРИМЕР 59. Григорий Одулов, заместитель генерального директора торговой компании: « К сожалению, множество проектов запускается только на основании предположений и допущений. И это не вина, а беда руководителей и владельцев компаний, что управление проектами превращается в управление рисками. Зачастую можно только предполагать, как то или иное «заинтересованное» ведомство (в лице конкретного чиновника) истолкует, в зависимости от ситуации, некоторый закон; как долго сохранятся действующие «правила игры», налоговая политика и т.д.»
Желательно, чтобы на Проектный комитет приносили уже готовые презентации текущих и возможных проектов, подготовленные в единой удобной форме,
1 См. п. 4.3.4 «Управление финансами в проекте».
которая позволяет руководству компании за минимальное время принять обоснованное решение. Проектный офис может оказывать методическую помощь руководителям проектов и инициативным группам по подготовке проектов к их представлению высшему руководству.
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 44
Опишите, как происходит отбор проектов в вашей компании на сегодняшний день. Насколько это оптимально, исходя из интересов бизнеса? Предложите оптимальную процедуру, а также критерии оценки и отбора проектов.
УСТАВ ПРОЕКТА
Очень удобно, когда все ключевые параметры проекта сведены воедино в документ, который называют устав (паспорт, декларация, карточка) проекта. Потом любому, кто должен ознакомиться с проектом, будет достаточно нескольких минут: хороший устав имеет объем 1-2 страницы.
Мой клиент - директор крупного интернет-магазина - вздрагивал, когда слышал «Устав проекта». В его предыдущей компании во Франции это был увесистый том под 100 страниц. При внедрении КСУП он поставил нам жесткое требование: «Минимум документов! А то работать будет некогда». Мы и не возражали.
Устав проекта утверждается высшим руководством компании. Он является «вершиной айсберга»: для подготовки качественного устава надо провести большую подготовительную работу. Кстати, презентацию нового проекта руководству можно готовить на основании его устава.
Каждая компания сама решает, какая информация должна входить в типовой устав их проекта. Например:
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 45
Изучите приведенную выше форму устава проекта применительно к своей компании. При необходимости внесите в нее изменения. Составьте устав ранее выбранного вами проекта на основе созданной формы. Это одно из ключевых заданий данной главы. Если для заполнения некоторых разделов устава вам пока недостаточно информации, вернитесь к этому заданию позже.
Экономические расчеты могут представляться в «Бизнес-плане» и/или «Технико-экономическом обосновании» (ТЭО).
В средней и крупной компании желательно заключать с менеджером проекта соглашение (контракт) конкретно на данный проект, даже если он работает в штате компании. Чтобы письменно зафиксировать его ответственность, критерии оценки результатов, «кнуты и пряники».
ПЛАН ПО ВЕХАМ
Еще один документ, который полезно составить на фазе инициации, - план по вехам. Веха - это ключевое событие проекта. План по вехам - последовательность вех проекта с предполагаемыми датами их наступления. Он помогает высшему руководству принять решение о запуске проекта, на его основе осуществляется контроль.
Часто руководители так радуются, создав план по вехам, что тут же рвутся начать выполнять проект. Хотя это еще только предварительное планирование: не ясен до конца перечень работ, их взаимосвязи и т.д 1
Вех не должно быть чересчур много: желательно не более 12. Полезно также планировать, каким документом будет подтверждаться прохождение той или иной вехи. Поскольку веха - это событие, то желательно формулировать названия вех в глаголах совершенного вида: «Подписано техническое задание» и т.п.
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 46
Разработайте план по вехам своего проекта: от запуска до завершения.
ПРОЧИЕ ДОКУМЕНТЫ
Каждая компания сама решает, какие еще документы нужны на этапе инициации проекта.
Например, еще на самом начальном этапе вы можете потребовать от инициаторов проекта краткую «Концепцию проекта» прежде чем двигаться дальше: ведь сбор подробной информации, ее анализ, проведение расчетов, различные согласования требуют затрат рабочего времени. И руководство может решить, что всю эту работу есть смысл делать только после предварительного одобрения проекта.
Опыт показывает, что четко и внятно изложить свои мысли на 1 странице или 2-3 слайдах могут далеко не все. Вот вам и первый фильтр для отбора проектов - причем работает он автоматически, без дополнительных управленческих усилий. А заодно - средство воспитания сотрудников.
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 47
Решите, какие документы нужны вашей компании на этапе инициации проекта. Включите все, что нужно, но и не разводите лишнюю бюрократию.
42£. СОБРАНИЕ ПО ЗАПУСКУ ПРОЕКТА
Когда решение о запуске проекта уже принято и утверждена команда, желательно провести собрание, на котором дать участникам отмашку: «Начали!» Довольно точно суть этого мероприятия передает английский термин «kick-off meeting» («start-up meeting»), что означает что-то вроде «собрание-пинок».
Собрание проводится для того, чтобы:
Публично утвердить начало проекта;
Объявить единую согласованную точку зрения на проект;
Заручиться согласием всех заинтересованных лиц, замотивировать участников.
Желательно, чтобы в нем приняли участие менеджер проекта, команда проекта,
высшее руководство организации, другие ключевые участники,
На собрании обычно менеджер проекта проводит его краткую презентацию, после чего отвечает на вопросы участников.
На выходе каждый участник должен четко представлять себе:
Какие задачи решает проект;
Кто руководит проектом;
Ключевых клиентов и стейкхолдеров;
Выгоды этих сторон от реализации проекта;
Внутреннюю организацию проекта, распределение ролей;
Параметры проекта: цели, объем работ, сроки, бюджет;
Основные трудности и методы их преодоления.
ПРАКТИЧЕСКОЕ ЗАДАНИЕ 48
Как уже говорилось выше, каждый проект должен иметь определенные заранее цели.
Цели проекта - важнейший элемент управления проектом, от которого в итоге во многом зависит успешность проекта.
Приведем следующий пример. В крупной компании начинается внедрение информационной системы управления взаимодействием с контрагентами. Руководство компании декларирует для команды проекта и будущего подрядчика по выполнению работ цели:
· повысить эффективность взаимодействия с контрагентами;
· увеличить клиентскую базу компании;
· увеличить количество положительных отзывов потребителей и уменьшить количество жалоб.
Команда проекта реализует проект в рамках бюджета, однако с запаздыванием сроков на два месяца. По окончании проекта информационная система не используется пользователями, руководство компании признает проект неуспешным и увольняет руководителя проекта. Необходимо отметить, что во многом причина такого провала кроется в неправильной постановке целей проекта.
Во-первых, цели поставлены неконкретно. Клиентская база могла быть увеличена на 20 контрагентов, что, конечно, очень мало, но, тем не менее, обеспечивает выполнение поставленной цели «Увеличить клиентскую базу компании». Аналогичная ситуация с количеством отзывов потребителей. Кроме того, достижение данных целей можно оценить только после того, как пользователи информационной системы начнут в ней работать и внесут соответствующие данные по истечении периода времени.
Во-вторых, как выяснилось к концу проекта, главной целью, которую команда проекта не учла, являлось завершение проекта именно к 31 декабря, так как к этой дате руководство компании должно было отчитаться управляющему совету о выполнении цели. Так как отчитаться о результатах было нельзя, деятельность руководителей была признана неуспешной в целом.
В третьих, в целях проекта и в ходе работ были не учтены интересы и желания сотрудников компании - конечных пользователей информационной системы, что привело к саботажу использования системы.
Таким образом, небрежная постановка целей часто приводит проект к провалу.
Цели проекта должны соответствовать требованиям SMART (Specific - Специализированные, Mesurable - Измеримые, Actively Influencible - Актуальные, Realistic - Реалистичные, Time Limited - Ограниченные по времени).
Для приведенного примера необходимо было определить цели:
· после завершения проекта 90% сотрудников используют информационную систему;
· система содержит актуальные данные;
· увеличить клиентскую базу компании на 20% за полгода использования системы;
· увеличить количество положительных отзывов потребителей на 10% и уменьшить количество жалоб на 10% за полгода использования системы.
Такие цели соответствуют требованиям SMART и позволяют команде проекта и руководству компании отслеживать показатели успешности проекта объективно.
Для оценки выполнения целей проекта вводят критерии успешности проекта. Проект успешен, если он:
· завершен в установленные сроки;
· в рамках выделенного бюджета;
· при удовлетворении заказчика.
Жизненный цикл проекта
Каждый проект, независимо от его сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет».
Начало проекта связано с началом его реализации и началом вложения денежных средств в его выполнение.
Окончанием существования проекта может быть:
· ввод в действие объектов, результатов проекта, начало их эксплуатации и использования результатов выполнения проекта;
· перевод персонала, выполнявшего проект, на другую работу;
· достижение проектом заданных результатов;
· прекращение финансирования проекта;
· начало работ по внесению в проект серьезных изменений, не предусмотренных первоначальным замыслом (модернизация);
· вывод объектов, результатов проекта из эксплуатации.
Обычно как факт начала работ над проектом, так и факт его ликвидации оформляются официальными документами.
Состояния, через которые проходит проект, называют фазами (этапами, стадиями).
Универсального подхода к разделению процесса реализации проекта на фазы не существует. Решая для себя такую задачу, участники проекта должны руководствоваться своей ролью в проекте, своим опытом и конкретными условиями выполнения проекта. Поэтому на практике деление проекта на фазы может быть самым разнообразным - главное, чтобы такое деление выявляло некоторые важные контрольные точки («вехи»), во время прохождения которых просматривается дополнительная информация и оцениваются возможные направления развития проекта.
Каждая фаза должна заканчиваться измеримым, проверяемым результатом. В конце каждой фазы принимается решение об инициации новой фазы или закрытия (консервация) проекта.
В свою очередь, каждая выделенная фаза (этап) может делиться на фазы (этапы) следующего уровня (подфазы, подэтапы) и т.д.
Пример жизненного цикла проекта приведен на рис. 1.3 .
Отражены:
· фазы проекта;
· вехи по началу и окончанию каждой фазы;
· результаты каждой фазы.
Выделение множества этапов в крупных проектах связано не только с большой продолжительностью строительства этих объектов (10-15 лет), но и необходимостью более тщательного согласования действий организаций - участников проекта.
Рассмотрим изменение характеристик проекта в течение жизненного цикла.
Что нарастает в ходе проекта и резко снижается к завершению рис. 1.4 
):
· уровень затрат;
· уровень загрузки персонала.
Что увеличивается в ходе проекта (рис. 1.5 
):
· вероятность успешного завершения проекта;
· стоимость изменений;
· стоимость исправления ошибок.
Что уменьшается в ходе проекта (рис. 1.6 
):
· неопределенность/риски проекта;
· возможность участников оказать влияние на конечные характеристики продукта проекта;
· возможность участников оказать влияние на стоимость продукта проекта.
Существует взаимосвязь жизненного цикла проекта и жизненного цикла продукта.
Жизненный цикл продукта состоит из фаз, которые отслеживаются для производственных и контролирующих нужд компании. В основном жизненный цикл проекта состоит из одного или более жизненных циклов продукта.
Если итоги проекта связаны с продуктом, возможно много видов взаимосвязей между жизненными циклами. Например, разработка нового продукта сама по себе может быть проектом. В качестве альтернативы можно привести пример, когда проект реализуется для улучшения характеристик существующего продукта.
Критерии успешности проекта.
| Наименование параметра | Значение |
| Тема статьи: | Критерии успешности проекта. |
| Рубрика (тематическая категория) | Технологии |
Критерии успешности проекта - совокупность показателей, которые дают возможность судить о степени успешности выполнения проекта.
Критерии успешности управления проектом - показатели эффективности управления проектом.
Успех проекта͵ как правило, означает получение всеми заинтересованными сторонами результатов, оправдывающих их ожидания, традиционно формулируемые в виде целей и требований. В случае если такие цели и требования сформулированы, критериями успешности проекта могут выступать количественные показатели, отражающие степень достижения целей проекта или выполнения определенных требований.
Четкое и однозначное определение этих критериев является обязательной задачей на начальном этапе запуска проекта. Руководитель проекта должен определить и согласовать показатели успешности и способы их оценки со всеми заинтересованными сторонами проекта.
Общий критерий успешности проекта - это достижение целей проекта в запланированное время и в рамках запланированных ресурсов.
Главным требованием к критериям является их однозначное и ясное определение. Для каждого проекта и каждого заказчика критерии успеха должны быть определены, оценены и проанализированы.
Факт недостижения поставленных в начале проекта целей не всегда означает неудачу в выполнении проекта. При этом если взгляды сторон на цели и задачи проекта меняются в ходе исполнения проекта͵ эти изменения должны найти отражение в соответствующих критериях успешности.
Понятие успешности управления проектами связано с успехом проекта͵ однако это не одно и то же. Можно успешно руководить осуществлением проекта͵ который впоследствии будет прекращен в связи с потерей актуальности, к примеру, из-за изменения стратегии компании. В случае если успех проекта обычно связан с достижением ожидаемого бизнес-результата͵ то успешность управления проектом обычно ассоциируется с такими критериями, как соблюдение ограничений по срокам реализации и стоимости проекта͵ своевременность поставок, качество коммуникаций, время реагирования на возникающие риски и проблемы и т.д.
В случае если в связи с происходящими изменениями проект теряет свою актуальность, крайне важно рассмотреть варианты внесения изменений в замысел или принимать решение о закрытии этого проекта.
Определяющим критерием успешности проекта является актуальность результата на момент его достижения .
В самом начале проекта весьма целесообразно проанализировать причины возможных неудач проекта (потенциальные зоны рисков).
Основными причинами неудач проекта бывают:
· неясные цели;
· недостаточное финансирование;
· изменение приоритетов бизнеса;
· недостаточная поддержка со стороны высшего руководства;
· неэффективная команда (квалификация персонала проекта);
· недостаточно эффективное взаимодействие в проекте;
· недостаток самоуправления;
· недостаточно эффективные коммуникации;
· отсутствие мотивации (относится к внутренним рискам);
Необходимо протестировать проект на ʼʼпричины возможных неудачʼʼ: достаточно ли ясны цели проекта? Степень надежности инвесторов? Достаточна ли квалификация команды проекта? Достаточна ли ее мотивация?
Критерии успеха и критерии неудач взаимосвязаны между собой. Но с течением времени они могут изменяться, в частности по мере изменения ситуации на рынке.
Критерии успешности проекта. - понятие и виды. Классификация и особенности категории "Критерии успешности проекта." 2017, 2018.
Продолжение следует...
Сегодня хочу в двух словах рассказать о критериях успешности проектов и проектных менеджеров.
Но сперва придется ответить на вопрос “что такое проект” :)
Это первый вопрос, на который необходимо ответить любому менеджеру.
Неочевидно, но проектное управление сложнее, чем “обычный”, так называемый “регулярный менеджмент”. Управлять отделом или подчиненными - это одно. Руководить проектом - совсем другое.
Большинство методологий проектного управления объемные. Например, последняя редакция “библии менеджеров” PMBoK составляет почти 1000 страниц, руководства Prince2, IPMA и другие (о них - как-нибудь в другой раз) - тоже не маленькие.
В жизни руководителя важно научиться быстро понимать “проект перед вами или нет”, чтобы не тратить силы (и попытки подтянуть 1.000-страничные методологии туда, где можно обойтись малой кровью).
Одно из первых открытий, которое предстоит сделать - высшее руководство само, как правило, плохо понимает где проекты, а где нет. Т.е. надеяться на то, что вам поручили нечто, назвали это проектом и уже хорошо подумали - не приходится. На практике проектами называют что попало, именно вам (проектному менеджеру) нужно проверить сказанное на адекватность.
Нам нужно определение, которое поможет сортировать поставленные задачи на те, которые требуют проектного подхода и те, которые (к счастью) можно решить проще, применяя более привычный большинству людей “регулярный менеджмент”.
Давайте вспомним или нагуглим более-менее классическое определение. Нам попадется что-то вроде: “Проект - это мероприятие для достижения какой-то цели, ограниченное во времени ресурсах и связанное с достижением уникального результата.”
Подобные формулировки встречаются часто. В том числе, в самом PMBoK. Проблема: они неудачные. Из них непонятно главное - чем проект отличается от “не проекта”.
Не верите? Попробуйте подобрать хотя бы один пример любой деятельности, который не подпадает под это определение?
Вы отправляетесь на работу или готовите себе утром яичницу на завтрак.
Это мероприятия для достижения цели? Конечно, цель вполне конкретная (прибыть в пункт назначения, насытиться).
Ограниченные во времени? Безусловно! Нельзя завтракать пол дня или потратить сутки на дорогу.
Ограничены ли ресурсы? Опять, да. У вас понятная сумма, которую можно и не жалко тратить на дорогу. Или в случае с яичницей - всего десяток яиц в холодильнике. Израсходуете их - останетесь без завтрака.
Нужно ли называть такую работу проектом? Конечно нет! Какие там 1000 страниц методологий, чтобы пожарить яичницу. Можно справиться одной интуицией и здравым смыслом.
Если бы вы готовили яичницу не один, а с семьей, передавая друг другу сковородку, то приготовление завтрака все равно не превратилось бы в проект, интуиции по-прежнему бы хватало.
Многие тренеры по управлению проектами любят пафос и склонны преувеличивать. Иногда они говорят “все на свете - это проекты”. Или “проектное управление - очень древнее умение, первым проектам тысячи лет - вот, египетские пирамиды...”.
Смею утверждать - строительство египетской пирамиды древними египтянами как раз не являлось проектом, как и приготовление яичницы. Проектов вокруг нас (к счастью), вообще, гораздо меньше, чем кажется. А в нормальном, современном смысле слова полноценный проектный менеджмент сформировался порядка 50-70 лет назад (вряд ли больше).
Однако, вернемся к яичнице.
А теперь представьте, что перед вами более сложная задача. Приготовить не просто яичницу на завтрак себе (или своей семье). Грядет какое-то событие (день рождения ребенка). Вы хотите сделать сюрприз - беретесь за яичницу из страусиного яйца.
Ставки резко возрастают. По-прежнему есть ограничения сроков (например, день рождения уже скоро). Есть всего одно яйцо, вы купили его на страусиной ферме. Вы очень мало знаете о страусах и не уверены - удастся ли его нормально прожарить. Непонятно даже - уместится ли оно на нормальной сковородке и разобьется ли корректно скорлупа. Вам очень не хочется ошибиться и испортить сюрприз ребенку.
И вот в такой ситуации, ваша деятельность начинает все больше напоминать проект. Вы начинаете более тщательно (по сравнению с привычным завтраком) планировать - лезете в интернет, выясняете “как жарить”, “как разбивать”, подбираете специальную сковородку (или даже покупаете в магазине подходящую, рассчитываете время. Не обязательно вся 1000 страниц PMBoK найдет применение в таком подходе. Но очень многие элементы, которые вам не пришло бы и в голову использовать для обычного завтрака или путешествия до офиса вы примените тут.
Позвольте предложить свое определение.
Проектом мы назовем работу над задачей, которой свойственны одновременно:
Конечность - это “рамки”, ограниченность в сроках и ресурсах.
Высокая неопределенность - говорит о том, что поставленную задачу до конца непонятно, как решить. Только когда ОБА условия соблюдаются - применяйте проектное управлении.
Вспомните основные индустрии и отрасли, в которых распространено проектное управление: например, ИТ или прикладная наука. Когда запускается проект по разработке и внедрению программного продукта или по выводу на рынок нового фарм. препарата - у них, как правило, есть рамки. Компания располагает определенным бюджетом и может позволить себе инвестировать в разработку на определенное время. Но затем деньги должны вернуться. При этом задача, которую будут решать софтверные инженеры, технологи и ученые - зачастую не имеет понятного алгоритма, она плохо предсказуема, может сработать множество рисков (приходится отчасти брать на вооружение принцип “ввяжемся в бой, там посмотрим”).
Вот на таком “стыке” очень плохо работают подходы из регулярного менеджмента. Когда одновременно имеются и очень жесткие рамки (конечность), и высокая неопределенность.
Вот почему (на мой взгляд) строительство египетских пирамид древними египтянами - не проект. Как минимум один из параметров отсутствует. И это - конечность.
Строительство пирамиды начинали, когда рождался фараон. Закончить нужно было к моменту его смерти. Если не случалось гибели во младенчестве, то, скорее всего, на постройку отводилось лет 20-30 как минимум. Ресурсы (люди, материалы) также не были дефицитными. Мнения расходятся - строили ли пирамиду рабы или свободные наемники, но, в любом случае, работал принцип - “что-то пошло не так? Давайте пригоним еще людей”. Если у вас не ограниченные сроки и / или бюджеты, то рано или поздно вы справитесь с любой задачей. Даже с очень сложной. И очень непонятной вам. С пятого-десятого-двадцатого раза, после огромных расходов - все у вас получится.
Пример “египетских пирамид” в современном мире - некоторые гос. проекты. Или работа некоторых продуктовых компаний (чаще в сфере ИТ). Когда фирма сделала некий ИТ-продукт и потом годами дорабатывает и совершенствует его, продавая все новым и новым клиентам, расширяя количество сервисов. Пока такая компания не выходит на новый уровень развития, но уже является очень богатой - она не нуждается в проектном управлении (представьте Google или Facebook). Сейчас это гигантские корпорации, занимающиеся множеством проектов от создания автомобилей и спутников до медицинских и финансовых стартапов. Но когда-то они имели 1 очень успешный продукт (поисковик или социальную сеть), и могли единственной своей задачей поставить его развитие (на что могли тратить, как минимум, неограниченное количество денег). Такому Google и такому Facebook управление проектами было бы не нужно.
Иногда упоминают так называемую “операционную деятельность”. Это самый очевидный пример, который только можно представить, когда проектное управление совсем не требуется.
Для операционной деятельности характерно нарушение обоих принципов: (бес-) конечность и (отсутствие) неопределенности.
Пример - работа автосборочного предприятия. Завод, на котором работает конвейер. По нему двигаются автомобили. Кто-то занимается покраской кузова, установкой колес, фар, сидений и так далее. Эта деятельность условно-бесконечна (она будет повторяться изо-дня в день, пока не закроют завод или не свернут производство этой марки машин). Она крайне предсказуема (хорошо известно сколько авто можно произвести за смену, какой будет “выхлоп” в конце дня, недели, месяца, года). Никакой пользы применение принципов проектного управления в таких условиях не даст (только все усложнит и запутает).
Другой пример операционной деятельности - работа технической поддержки в ИТ-сфере. Колл-центр или сайт принимает заявки, они по определенному алгоритму распределяются между сотрудниками, которые либо дают устные рекомендации пользователю, либо устраняют мелкие дефекты. Такая работа здорово напоминает сборочную линию: небольшие, чаще всего однотипные запросы на вход, предсказуемый алгоритм их отработки. По крайней мере, пока речь не заходит и масштабных перестройках системы. В таких условиях проектное управление тоже бесполезно.
Однако, когда вы сталкиваетесь одновременно с задачей, которая обладает высокой неопределенностью и конечностью (рамками), проектное управление лучший на сегодняшний день (с небольшими оговорками) способ ее решить.
Говоря об определении проекта важно упомянуть и критерии успеха. Кто такой “успешный менеджер”? Что такое “успешный проект”? И что считать провалом?
Ответ давно выработан методологами.
Успешный проект тот, который уложился в заранее определенные сроки, стоимость (и прочие ресурсы), предоставил заказчику то что тот просил и при этом ключевые заинтересованные стороны - удовлетворены.
Звучит громоздко, но легко передается одной картинкой. Представьте себе треугольник (его с некоторых пор перестали рисовать в PMBoK, но суть никуда не делась). У треугольника три грани = сроки, деньги, содержание. В центре - улыбающийся смайлик. Все.
Это критерии вашего успешного проекта.
Грани - то что согласовано с заказчиком до старта проекта. Обычно - такие договоренности высокоуровневые, в общих чертах, но они же - нерушимые. Пообещали построить дом из кирпича, 9-и этажный, в срок 12 месяцев и с бюджетом в 1 млн. долларов? Делайте!
Каким будет этот дом, как будут выглядеть балконы, лифты какой фирмы в него установить - второй вопрос. Об этом еще предстоит договориться, возможно - по ходу проекта. Но рамочные договоренности - сразу. До запуска проекта. Обычно их фиксируют в гипер-лаконичном документа под названием “устав проекта” (о нем как-нибудь в другой раз).
Итак, три грани проекта вы должны определить ДО того, как начнете работать. Сроки (“закончим не позднее, чем”), деньги (“бюджет проекта не больше, чем…”) и содержание в 2-3 предложения (“что делаем и чего не делаем”). Эти грани символизирует треугольник на картинке.
Достигнуть их нужно так, чтобы ключевые (не все, но ключевые) заинтересованные стороны проекта (ключевые пользователи и представители заказчика, ваше руководство, ключевые регуляторы и некоторые другие) были удовлетворены. Эту удовлетворенность символизирует смайлик внутри треугольника.
Хороший менеджер проектов отличается от плохого тем, что попадает в треугольник при завершении и ключевые заинтересованные лица при этом довольны.
Все методологии, по большому счету, ориентированы на то как сформировать треугольник на старте проекта с достаточной точностью и что делать по ходу, когда будут возникать отклонения (промахнулись с оценками, появились новые требования, сменился представитель заказчика и т.п.).
Менеджер не успешен, если не умеет удержать проект в треугольнике (который сам же при старте согласовал). Или если его проекты завершаются “в бюджет и в срок и строго по ТЗ”, но заказчик при этом остается глубоко несчастным и разочарованным (смайлик в треугольнике уголками губ вниз). Еще один пример неуспеха: проект завершен в рамках первоначально-означенного треугольника, заказчик доволен, но команда перенапряглась - люди в ней демотивированы, многие, получив проектный бонус, подали заявление об увольнении. Внутренняя репутация компании подпорчена, искать новых специалистов на рынке труда - трудно и дорого. В этом случае, вероятно, недовольны будут в высшем руководстве компании. А это тоже заинтересованные ключевые стороны (ведь проект делался на их деньги - именно они платили зарплату вам, как менеджеру и всем штатным сотрудникам).
Проектное управление - это балансирование: как определить и не провалить рамки треугольника (сроки-деньги-содержание) и добиться удовлетворенности ключевых заинтересованных сторон проекта. Это ключевое, что нужно помнить про критерии успеха проекта.
Статья написана на основании учебного курса по управлению проектами.
В результате освоения темы студент должен:
В задачи менеджера проекта входит обеспечение успешности проекта. Под успешностью принято понимать деятельность, сопровождающуюся успехом. Успех понимается по-разному: для одних это возможность улучшить собственное материальное положение, а для других - возможность помогать людям и чувствовать себя нужным. В толковом словаре рассматриваются три смысловых значения слова «успех»: «1) удача в достижении чего-нибудь; 2) общественное признание; 3) хорошие результаты в работе». Кроме того, выделяют понятие «истинный успех», характеризующее достижение полной гармонии материальной и духовной его составляющих. Согласно данной этимологии, успех в проектной деятельности может быть истолкован неоднозначно, а именно как: 1) положительные результаты на стадиях разработки, участия в конкурсе и реализации проекта; 2) достижение поставленных целей проекта;
3) общественное признание ценности проектной идеи, инновации и др.; 4) субъективные переживания командой проекта и командой управления проектами достигнутых ими результатов.
В отличие от выгодности показатель успешности имеет социальный аспект, содержит предмет социального одобрения. В проектной деятельности различают успешность проекта и успешность управления проектом. Успешность проекта характеризует свойства, своевременность и общественное восприятие проектного продукта,
а успешность управления проектом - соблюдение согласованных параметров проектной деятельности, профессионализм и слаженность работы команды проекта.
Под критерием понимается количественная и (или) качественная оценка того, как осуществляется приближение к цели. Следовательно, обеспечивая успешность проекта, менеджер проекта осуществляет оценку и балансировку целей проекта и выгод. Процесс такой оценки может включать множество критериев, как количественных, так и качественных, например согласованность со стратегией организации, социальную ответственность.
Состав критериев может отличаться от проекта к проекту. Для оценки успешности конкретного проекта разрабатывают критерии с учетом специфики оцениваемого явления. Большинство критериев требует разбиения их на более конкретные элементы 1 . При их моделировании и формализации возникает проблема выбора адекватных критериев или составления перечня надлежащих критериев. В проектной деятельности важно, чтобы критерии отражали стратегическую, финансовую, техническую и поведенческую ситуации организации и проекта. Поэтому задача оценки успешности проекта сводится к поиску компромисса между полнотой описания целей и количеством критериев. Для повышения точности оценки и управляемости рекомендуется сужать пространство критериев до нескольких жизненно важных и значимых показателей. Для этого сначала составляют полный перечень критериев успешности, а затем его прореживают.
Набор уместных критериев успешности зависит от типа проекта и конкретной проектной ситуации. Например, в перечень критериев успешности, которые учитываются при отборе проектов в сфере НИОКР, целесообразно включить стоимость проекта, его отдачу, вероятности технического и рыночного успехов, размер и долю рынка, доступность необходимого персонала организации, степень приверженности проекту, стратегическую ориентацию проекта, показатель конкурентоспособности, степень благоприятствования окружения и законодательства выполнению проекта; мнения руководителей компании. Кроме того, при построении критерия, как правило, учитываются интересы стейкхолдеров проекта.
Следовательно, оценка успешности проекта является многокритериальной. Но, как известно, в формальных задачах оптимизации критерий один - максимизация приближения к одной цели. Методика построения общего критерия предусматривает определение формы модели успешности с указанием конкретных категорий критериев, определение величин и (или) их диапазона и важности критериев, выбор методов их измерения. Причем в модели успешности проекта целесообразно учитывать критерии не только преимуществ, но и недостатков проекта. Предложены различные способы сведения множества критериев-элементов к одному, т.е. построения однокритериальной модели оценки. Один из примеров - модель ранжирования проектов рассмотрена в параграфе 12.2 учебника (формула (12.1)).
