От авторов
Проектный подход в последнее время становится новым модным трендом как в бизнесе, так и в госструктурах. На государственном уровне о необходимости внедрения проектного управления говорит уже президент, на конференциях по проектному управлению собираются сотни участников, увеличивается число сертифицированных специалистов, ежегодно растет количество проектных офисов в компаниях. Но эффективность управления проектами, ценность проектного офиса для компании и достижения ее целей очень различны. Профессиональное сообщество объединяет свои усилия для ответа на вопрос «Как сделать проектное управление реально полезным бизнесу?»
Перед вами книга, в которой представлены основные вехи внедрения проектного управления в компаниях разных сфер. Самое ценное в ней – это обобщенный опыт авторов и действительно работающие инструменты, которые доказали свою жизнеспособность и эффективность в работе над реальными проектами. Вам не придется рисковать – у вас есть уникальная возможность постичь нюансы проектного управления на нашем опыте, избежав собственных ошибок.
Вместо предисловия
«Что первично: софт или процессы?»
По роду своей деятельности мне часто приходится сталкиваться с вопросом: а нужно ли программное обеспечение для старта проектного управления в компании? Вопрос непростой и очень важный. Ведь начиная изменения в управлении, невозможно на 100% быть уверенным в их успехе. А программное обеспечение, как правило, требует вложений, и безотлагательных.
Когда я только начинала постигать тему проектного управления, я много училась: читала книги, статьи, участвовала в конференциях, ездила на обучающие курсы. Очень благодарна моему тогдашнему работодателю за щедрость и веру в мои силы. Посетила я много всего, летала в Москву чуть ли не каждую неделю. Во время обучения этот вопрос тоже задавали, а отвечали на него умудренные опытом педагоги и практики внедрения проектного управления. Сомневаться в их словах мне тогда не приходилось. Ответ их был однозначным и единым: не стоит внедрять программное решение до того, как будут выстроены процессы. То есть алгоритм примерно такой:
- решить, какие процессы вы хотите внедрить;
- попробовать их внедрить;
- удалить то, что не работает;
- добавить то, чего не хватает;
- утихомирить явных противников;
- обеспечить поддержку сторонников.
И только когда вы уверены в том, что это то, что вам нужно, и оно работает, можно задуматься о программном решении. Далее предполагается весь цикл управления закупками, описанный PMBoK: переговоры, выбор поставщика, контракт, проект внедрения и т.п.
PMBok (англ. Project Management Body of Knowledge) – свод профессиональных знаний по управлению проектами.
Все логично, красиво и... абсолютно не сработало у меня.
Объясню, почему.
Я работала в компании, в которой ИТ-решения были очень развиты, сотрудники и руководство ценили свое и чужое время, бюрократия была необходимым и мучительным звеном процессов, и с ней яростно боролись. При постановке нового процесса очень внимательно относились к возможностям для повышения эффективности, сокращению ручного труда, снижению времени выполнения операций, способам снижения рисков за счет автоматизации. Становление процессов проектного управления – не исключение. К ним отнеслись точно так же. И... купили решение для автоматизации процессов.
Да, возможно, это решение было необдуманным, рискованным и принятым в компании, которая могла себе позволить потратить определенную сумму денег. Но! Давайте я расскажу, какой был результат.
Программный продукт, который делает управление эффективным
Процессы управления и программное решение для их поддержки были внедрены за 9 месяцев. Компания в 3000 сотрудников получила единое централизованное управление инвестициями для собственного развития. Поддержкой программного продукта занимался один человек, работал он, кстати, без перегрузок. Период становления процессов был поддержан инструментом, который позволял выявлять проблемы онлайн и реагировать на них. Непосредственные исполнители проектов и их руководители помимо дополнительных бумажек получили инструмент для контроля самих себя, для организации своей деятельности и предупреждения проблем. Руководство получило единое окно для понимания статуса и понятный инструмент управления.
Программный продукт связал воедино «верх» и «низ» управления проектами и обеспечил слаженную работу. Уже после, когда система стала работать стабильно, мне с ее помощью удалось сделать крупнейшие проекты региона, эффективно управлять идеями, проектами и операционной деятельностью компании, в разы поднять скорость внедрения проектного управления и сократить до минимума просрочку исполнения. С этого успешного внедрения началась большая работа по распространению опыта организации проектного управления на другие компании: банки, фабрики, холдинги.
Пройдя этот путь, я сделала вывод, во-первых, о том, какие процессы являются действительно движущей силой, а какие – лишь глубоким дополнением к системе и, во-вторых, о роли программного продукта при внедрении процессов. Этими опытом я и хочу с вами поделиться в этой книге.
Технологии решают все
В вопросе использования программного продукта я не хочу ставить под сомнение профессионализм тех преподавателей и известных учебных центров, в которых я училась. Но я понимаю, чем они руководствовались. Действительно, если говорить о мировой практике, которая сконцентрирована в PMBoK, то мы должны следовать золотому правилу: «7 раз отмерь – один раз отрежь». Только для современного мира его нужно немного преобразовать.
Сейчас в жизни каждого из нас огромную роль играют технологии, они везде: на работе, в поликлинике, госструктурах, непосредственно под рукой – в мобильном телефоне. Все больше и больше людей разных возрастов привыкли, что технологии напоминают, записывают, сохраняют и обрабатывают информацию. Никто не хочет возвращаться к проводным телефонам, письмам в бумажных конвертах и рукописным налоговым декларациям. Технологии – надежные партнеры в нашей обычной жизни, которые делают ее проще и удобнее. Тем более, когда это касается нашей работы: все хотят работать быстро и эффективно, быть защищенными, получать качественную поддержку от программных продуктов.
Теперь представьте себе, что компания решила поставить процессы проектного управления без программного продукта и обкатать их в течение, например, полугода. Что это будет означать для рядового сотрудника? Появятся новые правила, новые документы, новые отчеты. Появятся люди, которые контролируют исполнение этих правил и качество этих документов. Появятся рычаги для мотивации, то есть неисполнение правил или их нарушение будет влиять на материальную составляющую конкретного человека. Итого – у вас в 2-3 раза больше головной боли. И вам придется значительную часть времени и сил отдать не на эффективное управление проектами, а на обеспечение «ручных» процессов.
Да, документы важны – их не может не быть. Они помогут избежать рисков, зафиксируют решения и соглашения, помогут определить необходимые правила для управления. Но в
«бумажном» виде это будет медленно, несвоевременно и даже опасно. Оформление документов, их согласование, поиск документов среди почты, объединение данных для отчетов руководству, быстрый сбор статуса для принятия решения – все это станет ощутимой проблемой для управления, которая может убить светлую идею системного управления проектами.
Кроме документов, важнейшим элементом управления проектами являются коммуникации и взаимодействие с заинтересованными сторонами: снова придется наполнять процесс необходимыми объявлениями, рассылками, отчетами и совещаниями, и все это, к сожалению, «вручную» с задержками и потерей важной информации. Даже если в компании есть системы документооборота, эти системы будут жить в отрыве от задач проекта, коммуникации с их помощью безжизненны и усложнены необходимостью дублировать информацию. Снова дополнительная нагрузка.
И даже руководство, наиболее защищенный и важный участник системы, не получит нужного эффекта от проектного управления без поддержки качественной информационной системы. Ведь потребность в информации будет не удовлетворена в связи с необходимостью ручного сбора нужной информации, ее быстрого устаревания, отсутствия возможностей для онлайн принятия решений. А качественная и своевременная информация – основа эффективного современного управления.
Пошаговое руководство к действию
Что же делать, неужели необходимо обязательно внедрять дорогие программные продукты и рисковать своими инвестициями? Совсем нет. Предлагаю вам подумать над несколькими простыми шагами для старта (упрощенный вариант):
Шаг 1. Определите тот перечень процессов, которые вам необходимы на старте. В этой книге мы как раз рассказываем о самых основных, которые и помогли мне в моем успешном опыте
Шаг 2. Определите пилотную зону – на каких проектах вы будете обкатывать эти процессы, кто участники этих проектов, какой они квалификации, что требуется этим проектам, их заказчикам и исполнителям.
Шаг 3. Зафиксируйте бюджет, который вы можете использовать для покупки программного продукта. Он может быть частью экономического обоснования внедрения КСУП или это может быть решением руководства.
КСУП – корпоративная система управления проектами. Аналог в российском ГОСТ: Система менеджмента проектной деятельности.
Шаг 4. Посмотрите решения на рынке и выберите в соответствии с вашим бюджетом. Для старта вам необходимо:
· решение, которое поддерживает требования к вашим процессам и уровню автоматизации – оно должно уметь делать все, без чего вы не представляете свою работу;
· простое решение, чтобы ваши сотрудники могли быстро понять, как в нем работать – дружественный интерфейс и возможность самостоятельного быстрого обучения;
· решение, позволяющее автономно его перенастраивать
– чтобы не тратить средства на программирование и кастомизацию (экономия на работе ИТ-специалистов и заказной разработке);
· решение, которое можно арендовать – возможность сразу не тратить огромные средства для серверных мощностей и не связываться с необходимостью собственной поддержки работоспособности;
· решение, которое используют крупные игроки – гарантия того, что что кто-то до вас уже «наступил на все грабли».
Управляем проектами системно
Конечно, вложение даже в недорогой инструмент – все же вложение, и предложенный мной способ – немного более затратный, зато и намного более жизнеспособный. Ведь если ваши сотрудники не поверят в возможность получения собственных выгод от системы, не увидят эффекта в собственной работе – система точно не заработает, а, возможно, и повредит управлению. Вторая попытка внедрения системы, даже если ее выполнять с закупкой софта, будет проходить гораздо сложнее и через определенный период времени. Задержка же внедрения системы неизбежно повлияет на получение эффекта от ваших проектов, достижение ваших целей, возможности для борьбы с конкурентами, развития и совершенствования.
Внедряя процессы и программный продукт одновременно, вы, с одной стороны, обеспечиваете персонал современным процессом (на который все и рассчитывают на старте) и не ставите под удар идею систематизации проектной деятельности. С другой стороны, у вас есть возможность обкатать ваши процессы в light-варианте и не рисковать тяжеловесными проектами внедрения сложного и дорогого софта.
Это и есть современная интерпретация того самого урока из PMBoK – попробовать на легком, проверить возможности (и информационной системы, и персонала, и процессов), сделать выводы и, наконец, принять решение о необходимых инструментах. Если процессы отстроены, есть понимание необходимых функций, сотрудники поддерживают систему – перейти на более сложные и дорогие инструменты вы всегда сможете, так же, как пересесть с одного автомобиля на другой. Ведь работающие правила, обученный персонал, организованная работа по принятию решений на основе программного решения – это и есть «системное управление проектами».
Рекомендации к использованию материала
Описываемые в этой книге процессы, их участники, шаблоны документов и примеры для применения являются универсальными подходами к организации управления проектами в любой компании. Однако в компаниях, реализующих крупные и сложные проекты для внешних заказчиков (проектные компании), чаще всего, требуются более детализированные документы, которые могут быть основаны на знании о специфике продуктов и клиентов таких компаний.
Также для корректного восприятия материала необходимо учесть значение используемых в книге определений. На практике встречается множество ролевых моделей управления проектом, для многих компаний понятие «проект» также отличается, но мы будем использовать следующие обобщенные определения основных понятий:
Проект – комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений. Для проектных компаний, которые специализируются на выполнении проектов и имеют для этого необходимые кадры и технологии, уникальность продукта/услуги) в основном связана с уникальными требованиями клиента (Заказчика), условиями эксплуатации продукта/услуги на территории Заказчика, используемыми внутренними ресурсами Заказчика. Для непроектных компаний и проектов внутреннего развития, большинство из которых выполняется впервые и без обеспечения подготовленного персонала, уникальность связана непосредственно с продуктом/услугой, возможностями его использования, методами и технологиями его производства.
Заказчик проекта – лицо, которое является владельцем результатов проекта, определяет (утверждает) требования к ним и является их основным приемщиком. Например, начальник отдела логистики может являться заказчиком проекта по переоборудованию складов, а директор торговой компании может являться заказчиком внедрения ERP-системы.
Куратор проекта – лицо, отвечающее за показатели деятельности, на которые влияют бизнес-цели проекта. Например, директор по продажам может курировать проект по созданию нового продукта. Куратор ответственен за обеспечение проекта ресурсами и осуществляет административную, финансовую и иную поддержку проекта, а также обладает достаточными полномочиями для решения указанных вопросов.
Руководитель проекта – лицо, осуществляющее оперативное управление проектом и ответственное за получение результатов проекта в условиях его ограничений, за соответствие результатов проекта требованиям качества и удовлетворении Заказчика проекта. Роль выполняется одним лицом и не может быть коллегиальной.
Глава 1. Зачем бизнесу проектное управление?
1.1. Чтобы выжить, нужно уметь меняться
Каким одним сводным понятием можно охарактеризовать внешнюю среду современного бизнеса? Мой ответ – изменения. А каким словом можно охарактеризовать внутреннюю среду организации, которая хочет соответствовать рынку и быть впереди конкурентов? Догадались? Точно – изменения. Оно включает в себя гибкость, постоянное изучение клиентов, улучшение процессов, вывод на рынок новых продуктов/услуг и так далее.
«Нужно бежать со всех ног, чтобы только оставаться на месте, а уж чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» © Льюис Кэррол, «Алиса в стране чудес».
Эта фраза в точности описывает ситуацию в сегодняшнем бизнесе. Если компания будет стоять на месте, то она будет терять в качестве своих продуктов и услуг, уступать рынок, терять доходы из-за возрастающей конкуренции, инфляции. Даже просто для выживания бизнес должен развиваться. А любые серьезные изменения, направленные на развитие бизнеса, это необходимость прийти из точки А в точку Б с заданными ресурсами в заданный срок. Это и есть проекты, даже если вы их так и не называете.
Управление одним проектом и управление группой проектов в организации подчиняются разным, но вполне определенным законам, которые просто необходимо знать каждой развивающейся компании.
1.2. Проекты как основной источник дохода
Конечно, инструменты управления проектами наиболее востребованы в проектном бизнесе. Именно тогда способность эффективного управления прямо влияет на доход компании, ее клиентов, репутацию, удовлетворенность персонала и многое другое. Проектный бизнес в подавляющем большинстве ориентирован на удовлетворение заказчика, выдерживание сроков, уклонение от рисков и эффективное управление ресурсами – это и есть основные направления проектного управления. Как бы то ни было, все такие компании управляют проектами, только одни эффективно, а другие нет.
Представьте себе строительную или ИТ-компанию, у которой нередко происходят задержки сроков. Заказчики не получают регулярной и достоверной информации о ходе работ, решения по изменениям проектов часто затягиваются, регулярно возникают простои из-за недостатка ресурсов. Как выживает эта компания? Скорее всего, сложно: заказы найти все труднее «благодаря» «сарафанному радио». У предприятия возникают постоянные кассовые разрывы по причине задержки между закупками и оплатой выполненных работ, большая текучка основного персонала из-за неудовлетворенности и роста конфликтов.
Какие выгоды может дать проектное управление в этом случае? Отвечу – огромные. Системное управление проектами для проектной компании позволяет разработать собственную технологию управления, которая снижает неопределенность (риск) каждого отдельно взятого проекта и ставит выполнение проектов на поток. То есть компания перестает работать каждый раз с новым проектом, она начинает работать с неким шаблоном: фаз, результатов, работ. При этом мы говорим не только о производстве как таковом, речь – о шаблонизации управления в целом.
Компания начинает применять технологии взаимодействия с заказчиками и внешними стейкхолдерами. Она выстраивает эффективную работу внутри себя между смежными подразделениями, системно контролирует риски и работает с ними. И все это под непосредственным контролем менеджмента, выделенных ответственных, которые реагируют на сигналы системы и своевременно предпринимают меры. Система сама себя совершенствует, и с каждым новым проектом компания становится все «умнее» и надежнее для своих клиентов.
Руководители проектов в такой компании точно знают, как реагировать на риски, какие следующие шаги в проекте, какие вопросы требуют немедленного решения. Исполнители ориентируются на четкий и согласованный с ними план исполнения, эскалируют вопросы и получают ответы вовремя. А заказчики… Скорее всего, заказчики довольны, что работают с таким партнером, который знает свое дело и умеет эффективно управлять проектом для получения наилучшего результата.
И даже если что-то пошло не так, то для компании с системой управления проектами это будет всего лишь случай, который разрешится и не повторится вновь. А для компании без возможностей проектного управления это может стать проблемой, не первой и не последней.
Кейс. Агрохолдинг, 15 000 сотрудников
КОМОС ГРУПП – один из крупнейших российских агрохолдингов.
15 предприятий, производящих продукцию под собственными торговыми марками. Дистрибуция, розничная сеть. 3 года назад компания начала активную реализацию проектов развития: строительство и реконструкция складских комплексов и производственных площадок, разработка и вывод на рынок новых торговых марок.
Отклонения по некоторым проектам доходили до 100% как по срокам, так и по бюджету. Финансовый директор холдинга решил взять ситуацию под контроль и захотел знать ФИО каждого ответственного за срыв сроков проектов.
Через 2 года средние отклонения по срокам и бюджетам проектов составляли не более 10% при портфеле проектов в 4 млрд руб.
1.3. Проекты как средство конкурентной борьбы
Рынок той или иной отрасли экономики меняется. Причем в зависимости от области это могут быть стремительные изменения (ИТ-сфера) или более спокойные, но масштабные изменения (в законодательстве или учете). Кроме того, идет конкурентная борьба: появляются и исчезают десятки новых игроков, лидеры рынка сменяют один другого, крупные «акулы бизнеса» уступают рыночные позиции молодым компаниям. Руководители предприятий так или иначе вынуждены решать задачу из книги
«Алиса в стране чудес». Ведь если не думать о том, как стать
номером один на рынке, то рано или поздно придется решать вопросы выживания.
Если компания активно растет или планирует рост, то это всегда большой вызов для топ-менеджмента и всей команды. Меняются процессы, а за ними и целые системы управления: маркетингом, продажами, производством, закупками, реализацией внешних проектов, разработкой, сервисом для клиентов и т.д.
Как правило, для гарантированного роста, небольших изменений недостаточно. К примеру, в вашей компании устарело оборудование, а на рынке появляются конкуренты, которые используют более современное оснащение (более экономичное, производительное, надежное). Вашу проблему не решить только лишь технологиями управления и выстраиванием отношений с заказчиками. Необходима срочная замена оборудования. А это значит, что необходимо найти поставщика по приемлемой цене, произвести тестирование, установку, настройку, запуск, обучение персонала и многое-многое другое. Для компании это огромный инвестиционный проект, который может помочь обогнать конкурентов и вывести вас в лидеры рынка или, наоборот, принести миллионные убытки и отбросить ваше развитие на шаг назад.
Примеров таких проектов, которые необходимы компании для собственного развития, десятки и даже сотни: внедрение новых систем учета, ERP и CRM систем, систем управления персоналом, в том числе учебных программ, запуск производства новых продуктов, рекламные кампании для продвижения бренда, перестройка существующих подсистем и линий для повышения эффективности и получения экономии и т.д. и т.п.
Каждый такой проект для собственника – это вполне конкретные инвестиции (зарплата сотрудников, оплата подрядчику, затраты на рекламу и пр.). И от его успешной реализации ожидается близкая по масштабу прибыль, а в случае неудачи или несвоевременного запуска – ее ощутимая потеря.
Например, если вы запускаете сайт, через который ожидаете получать больше запросов от клиентов, с опозданием на месяц, то получаете вполне конкретный убыток. Ведь новые запросы от клиентов стоят определенных денег и генерируют будущую прибыль. А если этот сайт должен был продавать ваше новое мероприятие, но запустился после даты его начала? Это, конечно, крайние сценарии, но они явно показывают: сроки реализации практически любого проекта развития напрямую влияют на прибыль компании.
Теперь представьте, вы вкладываете свои 10 млн руб. (бюджет портфеля проектов). Вы хотели бы получить гарантию, что деньги к вам вернутся и желательно с процентами? Конечно, но как это обеспечить? Как гарантировать, что проекты будут реализованы именно так, как мы задумали, и в указанные сроки?
Ответ – через системное управление проектами. В отличие от проектного бизнеса, работу по внедрению проектов внутреннего развития сложно облачить в единый шаблон, нет единого контура конечного продукта и специфики работ. Но процессы управления точно можно и нужно стандартизировать. Именно выстраивая процессы управления, компания обеспечивает себе качественное принятие решений, регулярный контроль за работами, быструю эскалацию вопросов. Она также гарантирует для себя распространение лучших практик управления среди персонала, качественные коммуникации и планирование ресурсов. Такой подход к управлению проектами в сочетании с современным программным продуктом дает мощный инструмент управления, который приводит к получению гарантированных результатов.
Кейс. Банк, входящий в ТОП-50 российских банков
Татфондбанк входит в 50 крупнейших банков России, около 3000 сотрудников, 94 подразделения и филиала. В сентябре 2013 года было принято решение о создании офиса управления проектами. На тот момент отклонения по срокам проектов составляли до 100%. В банке посчитали, что если хотя бы один проект (выпуск нового банковского продукта) благодаря выстроенной системе закончится на один месяц раньше, то полученная прибыль окупит инвестиции в создание проектного офиса и внедрение ИСУП.
Сказано – сделано. В 2015 году отклонения по срокам проектов уже варьировались в пределах от 5 до 15%, а к началу 2016 года подошли с нулевым отставанием. Вот у кого стоит поучиться проектному управлению, что мы, кстати, и делаем.
1.4. Резюмируя главу
Каждая компания ставит свои цели и выбирает свой путь их достижения. Если вы приняли решение, что хотите стать лидерами рынка или значительно повысить свои позиции, то рост возможен только через качественные изменения: продуктов, технологий, управления и т.д. Для любой компании такие изменения несут существенные риски, а, значит, они должны быть управляемы. Выстраивайте систему управления, основанную на принципах эффективного управления проектами и добивайтесь успеха.
Глава 2. Что такое «Управление по результатам»?
2.1. Почему ручное управление проектами не работает?
· Несмотря на большое количество проектов, компании не достигают своих стратегических целей.
· Результаты проектов не используются, а проекты часто затягиваются в бесконечную деятельность без результата.
· На уровне отделов – люди перегружены, а продвижение вперед – незаметно.
Почему это происходит?
Диалог с собственником крупной компании:
«У нас сейчас есть отдельная система управления задачами, еще раньше мы задачи учитывали в системе документооборота. Но, к сожалению, это не принесло нам особой пользы... То, что задача зафиксирована в отдельной системе не дает никакой гарантии, что она будет сделана».
Можно добиться хорошей эффективности от сильного руководителя, но сложно масштабировать его успех. Чем более сложная структура управления, тем сложнее контролировать в ней изменения и добиваться поставленных целей.
Управление деятельностью компании на разных уровнях содержит в себе значительные элементы уникальности, но результаты могут быть предсказуемы, только если в основе их получения находятся процессы регулярного менеджмента.
Какие именно? Рассмотрим далее.
2.2. Процессы регулярного менеджмента для управления по результатам
Основной задачей руководителя является стабильное и предсказуемое получение результатов и достижение через эти результаты целей компании. Поэтому управление, прежде всего, должно быть сконцентрировано на получении результатов.
Мы предлагаем использовать единый и универсальный подход:
Шаг 1. Сформулируйте конкретные измеримые результаты и требуемый срок их получения.
Шаг 2. Определите ответственных за получение результатов, согласуйте их обязательства по получению результатов.
Шаг 3. Регулярно контролируйте статус получения результатов.
Шаг 4. Предоставьте возможность ответственным вносить предложения по изменениям и своевременно реагируйте на озвученные риски.
Шаг 5. Определите лиц, способных оценить подготовленные результаты для применения в ваших целях.
Шаг 6. Определите мотивацию ответственных в соответствии с полученными результатами и сроками их передачи.
Общий вид этого процесса показан на рисунке 1.
Рис. 1. Модель управления по результатам
Эту последовательность шагов можно использовать не только для получения результатов при управлении проектами, это также будет работать и для квартальных планов отделов, и для получения результатов на уровне инвестиционных и стратегических программ предприятия или холдинга.
2.2.2. Как это работает на уровне программы или портфеля проектов?
На первом шаге определяются стратегические цели и требуемые измеримые результаты. Каждый результат может быть получен в рамках отдельного проекта, подпрограммы или стратегической задачи. На уровне Первого лица и акционеров утверждается стратегический план, определяются ответственные за исполнение всей программы и отдельных ее элементов.
Программа проектов – ряд связанных друг с другом проектов и задач, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности.
Портфель проектов – набор проектов, программ проектов и других работ, объединенных вместе для достижения более эффективного управления и обеспечения выполнения стратегических целей организации.
Ежеквартально или раз в полугодие собирается информация по исполнению плана и представляется высшему руководству.
На основании представленных результатов и их отклонений определяются необходимые изменения и принимаются требуемые решения для достижения установленных целей. Когда требуемые результаты получены – их оценивают и принимается решение об их использовании.
2.2.3. Как это работает на уровне управления проектом?
На уровне управления проектом, в первую очередь, утверждаются цели и результаты проекта, которые фиксируются в Уставе проекта. На основании Устава определяются планы получения контрольных результатов – фиксируются промежуточные результаты и сроки их получения.
В момент запуска проекта утверждается базовый план, относительно которого далее анализируются все отклонения. Руководитель проекта регулярно собирает информацию о выполняемых работах и сравнивает фактические показатели с плановыми.
При необходимости могут быть сформулированы требуемые изменения, а если приняты решения об их включении в план – такое решение формально утверждается и план корректируется. При получении результатов Заказчик анализирует отклонения содержания результатов. А на основании отклонений по срокам и бюджету, а также удовлетворенности Заказчика результатами рассчитывается мотивация проектной команды.
Цели работы отдела, как правило, фиксируются в положении по подразделению, или могут быть установлены годовые цели и показатели. Для ежемесячных планов отдела правильно определить промежуточные конечные результаты, которые требуется получить, сформировать план их производства, определить ответственных конечных исполнителей. План должен быть зафиксирован – в системе для контроля работ, на общем сетевом ресурсе, в кабинете на доске. Главное, чтобы план был всем виден.
Начальник отдела должен регулярно собирать отчет по выполнению работ, анализировать существующие риски и всячески способствовать выполнению работ в срок. В том числе, могут приниматься решения о корректировке планов, которые должны вноситься в учетную систему (систему распределения работ).
Полученные результаты должны приниматься с точки зрения полноты и качества, и на основании этих показателей исполнителям должна рассчитываться мотивация, например, от таких показателей может зависеть квартальная премия.
2.3. Что такое «Система управления проектами»?
Поскольку причины срывов проектов кроются на разных уровнях управления – от исполнителей работ и до высшего руководства, устранить их может только системное управление, работающее на всех уровнях компании.
Корпоративная система управления проектами (далее – КСУП), если говорить простым языком, представляет собой три основных элемента:
· свод правил, разработанных для управления проектами;
· выделенные подразделения, которые осуществляют контроль за исполнением таких правил;
· участники проектов, которые обучены этим правилам и должны их соблюдать.
Основой КСУП является информационная система управления проектами (далее ИСУП), которая ведет участников проектной деятельности по процессу, сводит необходимую информацию для контроля соблюдения правил и хранит данные о проектах.
Также неотъемлемыми частями КСУП являются нормативные документы (регламенты, методики, шаблоны и т.п.), система мотивации и система обучения персонала. В общем виде структура КСУП представлена на рисунке 2.
Рис. 2. Корпоративная система управления проектами
Построение такой системы является непростой задачей. И чем более зрелой является компания с точки зрения обеспечивающих элементов, тем более сложной является построение КСУП.
С чего начать?
Для построения КСУП нужно начать с простых, но твердых шагов.
Шаг 1. Определите процессы проектного управления, которые, прежде всего, должны контролироваться системой.
Шаг 2. Определите правила выполнения этих процессов.
Шаг 3. Назначьте ответственных за контроль правил.
Шаг 4. Обучите персонал правилам.
Шаг 5. Подготовьте информационную систему.
И, пожалуй, самое главное – верьте только системе и решайте вопросы через ее инструменты. Продолжая ручное управление проектами даже в исключительных случаях, вы не только не используете систему, но и закрываете путь для ее развития и отнимаете веру своих сотрудников в ее возможности.
Будьте про-активны:
· чего-то не хватает – добавляйте процессы;
· что-то не работает – корректируйте правила и обучайте персонал;
· слишком много ручных операций – донастраивайте информационную систему.
2.4. Основные процессы управления проектами
Какие процессы, прежде всего, нужно настроить для улучшения управляемости проектов и получения эффекта масштаба?
Как известно, в управлении проектами есть 10 групп процессов (все группы процессов представлены на рисунке 3. Выстраивание работы по всем фронтам является крайне сложной и даже невыполнимой задачей на первых шагах к построению системы. Для быстрого получения результата необходимо сосредоточить усилия над процессами, которые дадут максимальный эффект. Такие процессы должны использоваться во всех (или в абсолютном большинстве) проектах вне зависимости от особенностей бизнеса, и внедрение этих процессов не должно требовать значительной перестройки общих подходов организации к ведению бизнеса.
Рис. 3. Группы процессов управления проектами
Поскольку модель управления по результатам отражает управление малыми и большими формами задач, то предлагаем определить процессы на основании этой модели.
Первоочередные процессы для управления по результатам:
1) Определение целей и старт проекта;
2) Создание и утверждение плана работ;
3) Исполнение работ и подготовка отчетности;
4) Организация регулярных коммуникаций;
5) Оценка выполнения и принятие решений;
6) Приемка результатов и оценка;
7) Мотивация персонала.
Конечно, некоторые процессы, например, «Управления закупками» являются «больным местом» для многих компаний.
Однако этого процесса не указано в приведенной выше последовательности. Почему?
Дело в том, что всегда будут компании, для которых указанный перечень процессов не будет достаточен для построения КСУП. Ведь каждая КСУП уникальна и всегда зависит от среды, в которой живет компания: от ее клиентов, сотрудников, исторически сложившихся обстоятельств. Но для каждой компании построение указанного перечня процессов будет являться необходимой основой для построения ее собственной системы, в которую нужно будет добавить недостающие элементы.
Глава 3. Проектный офис
3.1. Что такое и для чего нужен Проектный офис?
Существует множество вариантов организации Проектного офиса. Каждая компания, в зависимости от потребности менеджмента, уровня зрелости и ресурсов, организовывает свой вариант этой структуры и понимает под его задачами свой собственный набор. В некоторых случаях возможно удачное совмещение функций и появляется органичное и полезное подразделение. Но нередко возникают так называемые Проектные офисы с набором непонятных и даже ненужных функций, которые вряд ли могут принести заметную пользу их создателям. Профессионалы, которые занимаются управлением проектами и созданием систем проектного управления (КСУП), понимают, что правильно организованный Проектный офис действительно продвигает выполнение проектов, совершенствует систему менеджмента и процессы управления, способствует достижению проектных целей и своевременному получению результатов. И наоборот: неверно организованная работа этого подразделения вредит становлению КСУП в компании, может снизить интерес топ- менеджмента к проектному управлению и породить конфликты исполнения процессов управления на уровне исполнителей.
Для начала давайте определим понятие «Проектный офис», которое и будем использовать в этой книге, для этого обратимся к международным стандартам. Во избежание путаницы договоримся, что не будем разделять понятия «Проектный офис» и «Офис управления проектами», и будем употреблять оба понятия как синонимы друг другу.
Проектный офис – организационная структура, которая стандартизирует процессы руководства проектами и способствует обмену ресурсами, методологиями, инструментами и методами. Степень ответственности Проектного офиса может варьироваться от оказания поддержки в управлении проектами до прямого управления одним и более проектами (@PMBoK Guide 5th).
Согласитесь, определение весьма широкое и не позволяет понять, что же это все-таки за структура, постоянная она или временная, кому подчиняется, какие у нее полномочия и ответственность. Это приводит к широкому размаху интерпретаций в организации Проектных офисов и, конечно, к ошибкам.
Для понимания разделим понятие на три основные группы:
1) Корпоративный Проектный офис (далее КПО) – самостоятельное постоянное структурное подразделение, отвечающее за поддержку и развитие корпоративной системы проектного управления в масштабе организации. КПО – владелец процессов проектного управления в организации.
2) Управляющий Проектный офис – самостоятельное постоянное структурное подразделение, отвечающее за управление выделенным направлением проектов, накопление и развитие компетенций, навыков, методик, техник и инструментов выполнения работ в рамках этого направления.
3) Администрирующий Проектный офис – временное структурное подразделение (возможно, не выделенное в самостоятельную структурную единицу), отвечающее за координацию работ, администрирование и организацию управления конкретным проектом или программой проекта, а также совершенствование этих процессов.
То есть все три направления создаются для достижения разных целей и несут совсем разные эффекты:
- Корпоративный Проектный офис, прежде всего, нужен, чтобы централизовать управление, ввести единые правила и стандарты, сохранить в компании приобретаемый опыт, собрать воедино картину движения по проектам (их бюджеты, цели, ресурсы и т.п.), а также сделать все возможное, чтобы основные процессы инициации, завершения, принятия решений становились лучше (быстрее, эффективнее, менее рискованными и т.д.).
- Управляющий Проектный офис сосредотачивает свои усилия над непосредственно управлением проектов определенной специфики, например, строительстве, ИТ, организации событий и т.п. Задача этого вида Проектного офиса – воспитывать, поддерживать и развивать компетенции руководителей проектов, распространять лучшие практики управления, опираясь на специфику работ, снижать риски управления, культивировать профессиональные подходы к управлению и общую культуру среди проектных команд.
- Администрирующий Проектный офис необходим для централизации управления конкретным проектом или программой проектов. Он хранит, обрабатывает и анализирует информацию по исполнению проекта/программы и способствует более эффективной работе его руководителя. Можно сравнить такой Проектный офис с секретариатом, который все учитывает, записывает и своевременно напоминает.
Каждая группа отличается уровнем управления, подчинения, составом персонала, функциями и полномочиями. Если говорить о структуре подчинения, то эти три направления можно определить так:
Вид Проектного офиса |
Управление |
Подчинение решениям |
Состав |
Корпоративный |
Первое лицо |
Проектный комитет |
Проектный директор |
|
|
|
Методологи ПУ Контролеры Администрато ры ИСУП |
Управляющий |
Руководитель направления бизнеса (директор по ИТ, директор по продажам, директор по консалтингу и т.п.) |
Корпоративн ый Проектный офис |
Проектный директор Руководители проектов |
Администрирую щий |
Руководитель проекта/програм мы |
Корпоративн ый Проектный офис Управляющи й Проектный офис |
Администрато ры проектов |
Функции и полномочия Управляющего и Администрирующего Проектных офисов всегда зависят от конкретного направления бизнеса (его специфики, внешних требований к его продуктам, уровню компетенций и т.п.) или конкретного проекта/программы (плана его коммуникаций, состава участников, методов выполнения работ и пр.). Поэтому в этой книге мы будем говорить о наиболее значимом в процессе построения КСУП варианте – Корпоративном Проектном офисе (КПО). Далее по тексту будем его называть Проектным офисом, подразумевая именно корпоративный вариант.
Основное назначение такого варианта Проектного офиса это:
- Разработка единых стандартов управления (процессы, методики, формы, шаблоны);
- Центр координации проектов, реализуемых разными функциональными подразделениями;
- Основной источник независимой информации о ходе выполнения проектов («общая картина» выполнения проектов для руководства);
- Центр компетенции, консультаций и наставничества (методологическая и организационная помощь руководителям проектов и программ);
- Центр аналитики и мониторинга (своевременная информационная поддержка принятия решений для руководства).
3.2. Цели и функции Корпоративного Проектного офиса
У многих компаний возникает логичный вопрос: если модель управления по результатам известна, внедрены основные процессы управления и внедрена информационная система, заменит ли это необходимость создания Проектного офиса? Конечно, нет. Давайте разбираться в этом.
Важнейшей задачей КСУП является выстраивание эффективных процессов управления проектами, создание корпоративной культуры для их выполнения, что приводит к гарантированным результатам проектов, а, значит, и к плановому достижению целей компании, ее росту, развитию и укреплению позиций на рынке.
Проектный офис (далее ПрОф) – владелец процессов проектного управления. Это означает, что именно ПрОф наделен правами и полномочиями для управления процессами и их контроля, кроме того, именно ПрОф несет ответственность за результаты процессов, а также управление процессами и их улучшение. Ни один топ- менеджер не возьмет на себя эту сложную и важную функцию. Это ежедневная работа, результат которой отражается на всех участниках проектов, их Заказчиках, инвесторах и пользователях результатов, поэтому все понимают, что для этой роли требуется отдельно выделенный ресурс. Таким образом, именно создание ПрОф является необходимым и важнейшим шагом становления КСУП.
Какие же функции должен выполнять Проектный офис? Чтобы ответить на этот вопрос, прежде всего, необходимо хорошо подумать о том, для чего нужен Проектный офис, какие цели ставит перед собой организация, создавая эту структуру. Сформулировать цель создания ПрОф – сложная и важная задача, которая определяет и функции Проектного офиса, и может заложить основы мотивации этого подразделения, определить ключевые показатели эффективности. К сожалению, многие определяют цели ПрОф без должного внимания: быстро, бездумно и условно. Наверное, и вы не раз сталкивались с документом «Положение о подразделении», в котором написано много красивых и умных слов, которые не несут за собой ничего конкретного. Очень часто именно так и выглядит документ «Положение о Проектном офисе». Что обычно написано в таком документе, изображая цели проектного офиса:
- наведение порядка;
- централизация и стандартизация управления;
- совершенствование процессов проектного управления;
- обучение персонала методам управления проектами;
- повышение ценности от реализации проектов.
Нередко в целях создания Проектного офиса пишут даже что-то вроде «Достижение стратегических целей компании». Хотя всем понятно, что достижение стратегических целей – основная задача топ-менеджмента, которая не может быть переложена на такую структуру как ПрОф.
Приведенные примеры «целей» можно отнести к направлениям деятельности или просто лозунгам, которые не обязывают сотрудников Проектного офиса ни к чему конкретному. При анализе подобных документов могут возникнуть новые вопросы: для чего нужна централизация и стандартизация управления? Что это должно принести организации? Что должно измениться после того, как централизация будет выполнена? Ведь именно в этом главный вопрос постановки цели: для чего?
Как топ-менеджер, по этим целям вы никогда не сможете понять, достигаются они или нет, как движется Проектный офис к этим целям, в чем он преуспел, а с чем есть проблемы. Зачастую в этом кроется корень зла: то есть именно непонимание целей ПрОф приводит его к неэффективной работе, конфликтам с проектными командами и топ-менеджментом и даже «смерти» Проектного офиса, так как его результаты становятся непонятными, ненужными, а содержание – затратным.
Далее в книге мы подробно остановимся на том, как правильно формулировать цели, как определять результаты и достигать их. А пока можем только привести примеры целей Проектного офиса, которые помогают оценить эффект от работы этой структуры и определить ее функции. К таким целям можно отнести:
- Повышение удовлетворенности от управления проектами (сверху – руководство и снизу – проектные команды);
- Сокращение отклонений от плановых сроков/бюджетов по типовым проектам;
- Снижение сроков принятия решений по проектам/программам;
- Повышение уровня компетентности персонала методом управления проектами;
- Сокращение сроков подготовки отчетности по портфелю проектов.
Конечно, для каждой такой цели должен устанавливаться конкретный срок ее достижения, а также показатель (измеритель цели). Например, повышение уровня компетентности персонала можно измерять в количестве сертифицированных специалистов (внутренняя или внешняя сертификация) или просто в числе обученных специалистов. То есть каждая цель должна отвечать на вопросы: какая выгода компании от Проектного офиса? Как измерить достижение этой выгоды? Только тогда вы сможете четко сформулировать нужные функции, поставить задачи и понимать, как вы движетесь к этим целям.
Для каждой компании будут свои выгоды, и именно топ- менеджмент должен определить цели создания ПрОф и контролировать их выполнение. Вообще топ-менеджмент – основной заказчик и выгодоприобретатель создания этой структуры, так как ПрОф, как часть КСУП, призван способствовать достижению стратегических целей и бизнес-выгод. Для определения целей ПрОф важно опросить именно руководство компании и сформулировать цели на основании его потребностей. Как это сделать? Попробуйте перед предложением о создании ПрОф проанкетировать высший руководящий состав, спросить, какие проблемы есть сейчас в управлении проектами для них, что может помочь в решении, показать возможные выгоды от КСУП, привести примеры наиболее значимых выгод. Как правило, топ-менеджеры в отсутствии КСУП сильно погружены в выполнение важных проектов, они понимают необходимость улучшения этих процессов, понимают боли и потребности изменений. Действительно неравнодушные менеджеры всегда ответят на такой запрос и, возможно, станут заказчиками внедрения КСУП и партнерами ПрОф в будущем.
Если говорить о наиболее популярных функциях ПрОф, которые он, чаще всего, выполняет, и целях, на которые они направлены, то можно выделить следующие:
Функция |
Выгоды/цели |
Разработка и развитие методологии управления |
Снижение конфликтов относительно процедур управления, повышение скорости процессов управления, снижение рисков и повышение компетенций управления |
Формирование сводной отчетности по портфелю проектов для топ- менеджмента |
Повышение скорости получения информации о статусе выполнения проектов, снижение рисков ресурсных конфликтов, повышение скорости принятие решений, повышения удовлетворенности заинтересованных сторон |
Контроль корректности использования методологии |
Снижение управленческих ошибок, повышение уровня компетентности персонала, снижение рисков |
Контроль достижения проектных целей |
Рост количества проектов с достигнутыми целями, повышение удовлетворенности заинтересованных сторон |
Обеспечение (организация) Проектного комитета |
Повышение скорости принятия решений, снижение уровня конфликтов между заинтересованными сторонами проекта, повышение удовлетворенности заинтересованных сторон, снижение рисков принятия решений |
Настройка и поддержка ИСУП |
Снижение затрат на управление, снижение рисков человеческого фактора, снижение уровня просрочки выполнения проектных работ, повышение удовлетворенности заинтересованных сторон |
Обучение проектного персонала |
Повышение уровня компетентности персонала методом управления проектами |
Подготовка данных для мотивации проектного персонала |
Снижение уровня конфликтов между участниками проектных команд, повышение уровня удовлетворенности заказчиков проектов |
Приведенные функции являются основой построения КСУП, но, конечно, не покрывают все ее потребности. При построении процессов управления функции должны быть дополнены. Примером декомпозиции функций может быть конкретизация функций ПрОф для базовых процессов управления по результатам:
|
Этап модели управления по результатам |
Функция Проектного офиса |
1 |
Установка целей. Фиксация результатов |
- Организация и модерирование совещаний для разработки Устава проекта; - Подготовка первой версии Устава; - Согласование Устава проекта относительно используемой формы (должен быть единый шаблон), соответствие цели требованиям SMART, формулировка контрольных точек; |
|
|
- Контроль сроков процесса инициации проекта и информирование заинтересованных лиц о просрочке. |
2 |
Формирование и утверждение плана |
- Контроль согласования плана по форме и содержанию: формулировка контрольных точек, согласование результатов и сроков с исполнителями и приемщиками, утверждение выделения ресурсов; - Сохранение плана в ИСУП. |
3 |
Сбор отчетности по выполнению |
- Обеспечение сбора регулярной отчетности по проектам на уровне Руководителей проектов: · актуализация статуса выполнения задач; · предоставление рисков и прогнозов выполнения контрольных точек высокого уровня; · предоставление требуемой информации о выполнении этапов и фаз; · учет движения денежных средств; - Подготовка сводной отчетности по портфелю для топ-менеджмента; - Подготовка сводной отчетности для Кураторов и спонсоров проектов; - Обеспечение коммуникаций проектных команд: регулярное проведение проектных совещаний, фиксация протокола. |
4 |
Оценка выполнения и принятие решений |
- Сбор вопросов для принятия решения; - Организация регулярных заседаний Проектного комитета и подготовка требуемых отчетов, а также фиксация решений и контроль их исполнения; |
|
|
- Информирование заинтересованных сторон о принятых решениях. |
5 |
Приемка результатов |
- Согласование итогового отчета проекта относительно используемой формы (должен быть единый шаблон), фиксация отклонений, анкетирование Заказчика по удовлетворенности проектом; - Проведение анализа выполнения проекта для фиксации лучших практик; - Архивация документов проекта. |
6 |
Расчет мотивации ответственного |
- На основании утвержденных правил и на основании данных итогового отчета подготовка данных для расчета материального вознаграждения или определения иных форм мотивации. |
Пример процессов под контролем Проектного офиса представлен на рисунке ниже.
Пример процессов с контролем Проектного офиса
3.3. Состав Корпоративного Проектного офиса
Состав Корпоративного Проектного офиса зависит от нескольких факторов: целей создания ПрОф, выполняемых им функций, существующей инфраструктуры компании, количества проектов в портфеле, управленческой зрелости компании и многих других. В этой книге мы рассмотрим возможный состав исходя из уникальных компетенций, которые могут потребоваться этому подразделению. Итак, какие уникальные компетенции могут быть полезны именно сотрудникам ПрОф:
- Коммуникации – способность договариваться о правилах, выявлять ключевую информацию, формулировать итоги совещаний и т.п.;
- Анализ и расчеты – способность рассчитывать экономическую целесообразность проектов или решений в проектах, рассчитывать доходность компании, выявлять требуемые статьи затрат или дохода;
- Документирование – способность создания понятных и полных документов для сотрудников и руководства (регламенты, методики, шаблоны и формы);
- Настройка ИСУП – способность настраивать существующие ИТ-инструменты под потребности процессов проектного управления, в том числе отчеты, представления и дашборды, реквизиты и справочники, печатные формы и другое;
- Взаимодействие с топ-менеджментом – способность презентовать результаты работы по портфелю (достижение результатов проектов, исполнение финансового плана, достижение проектных целей, использование ресурсов и прочее) на высшем уровне.
Исходя из представленных компетенций для ПрОф важно выделить несколько ключевых ролей:
· Руководитель проектного офиса (Проектный директор)
· Методолог
· Администратор проектов/программ
· Администратор ИСУП
· Другие роли:
o Тренер
o Менеджер по ресурсам
o Координатор программ
o Координатор портфеля
o Аналитик
3.3.1. Роль: руководитель Проектного офиса (Проектный директор)
Руководитель такого подразделения как ПрОф исходя из структуры подчинения сам должен являться топ-менеджером или близким к нему по должности. Важно найти человека, способного не только организовать работу этого подразделения, но и на равных взаимодействовать с руководством компании, защищать интересы стратегии на уровне топ-менеджмента.
Как правило, функциями этой роли являются:
- Контроль соответствия проектов целям организации;
- Контроль процессов управления портфелем и программами;
- Организация и контроль процесса приоритезации портфеля;
- Обеспечение представления сводной отчетности по исполнению портфеля;
- Контроль применения корпоративной методологии и инструментов управления;
- Контроль сроков и качества ключевых проектов;
- Обеспечение Проектного комитета и руководителей портфеля/программ необходимой информацией для принятия решений;
- Организация работы ПрОф.
3.3.2. Роль: методолог Проектного офиса
Методолог Проектного офиса – необычайно важная роль. На эту должность должен быть назначен сотрудник с высоким уровнем экспертности в проектном управлении. Как правило, для выполнения функций методолога требуется сертификация на основе используемого стандарта или, если стандарт еще не выбран, одного из крупнейших стандартов. Именно методолог будет определять инструменты управления системой, и от его работы зависит, насколько они приживутся в организации, насколько эффективно их можно будет использовать, какую пользу они смогут принести. Очевидно, что как минимум половина успеха работы правила зависит от содержания этого правила. Поэтому работа методолога является ядром ПрОф и всего проектного управления.
Основные функции методолога:
- Формирование корпоративных стандартов и методологии их применения, в том числе описание процессов проектного управления;
- Интеграция инструментов управления проектами с другими системами менеджмента;
- Проектирование корпоративной базы знаний по проектам;
- Разработка корпоративной системы отчетности;
- Выполнение аудитов проектов;
- Внутреннее обучение и сертификация.
Нельзя не заметить, что на роль методолога должен быть назначен человек с практическим опытом как руководства проектами, так и внедрения систем проектного управления. Назначение даже очень дорогого специалиста с множеством регалий может загубить построение проектного управления, если предлагаемые методы будут несовместимы с жизнью компании, если автор методик не будет представлять живого процесса управления, проблем команд, задач руководителя.
Возможно совмещение в этой роли опытного внешнего консультанта и внутреннего сотрудника, так как для многих компаний проблематично подыскать человека с нужными компетенциями. В этом случае внешний консультант обеспечит нужный уровень экспертизы, а внутренний сотрудник не позволит использовать методы, не совместимые с культурой компании.
3.3.3. Роль: администратор проектов/программ
Для многих Проектных офисов полезно иметь в своем составе сотрудников, которые смогут профессионально обеспечить процессы проектного управления. Особенно это важно для выполнения крупных проектов и программ, где у руководителя проекта попросту не остается на это времени. Также эта роль полезна в начале внедрения КСУП, когда важно не задавить еще слабых руководителей проектов требованиями к соблюдению внутренней методологии, а показать инструменты управления, их выгоды и наладить рост корпоративной культуры. В этих случаях необходимы такие сотрудники, как администратор проектов и программ, важнейшей компетенцией которых являются коммуникации. Ведь непосредственно через коммуникации с руководителем, Заказчиком, участниками команды проекта администратор доносит проектную культуру, прививает ее, обосновывает ее значимость и эффект.
Основные функции администратора проектов/программ:
- Поддержка процессов проектного управления, обеспечение корректности документов и процедур;
- Соблюдение корпоративной методологии (консультации руководителя) при выполнении отдельного проекта;
- Организация регулярных обязательных коммуникаций (с Заказчиком, командой, поставщиками и т.п.) и подготовка для этого необходимой отчетности;
- Поддержка документооборота;
- Актуализация базы знаний.
3.3.4. Роль: администратор информационной системы управления проектами
ИСУП является довольно важной частью корпоративной системы управления проектами. Поэтому очень важно, чтобы работа с ИСУП была удобной, гибкой и понятной. Как правило, ИТ- решениями, их настройкой, поддержкой и обучением в организации занимается выделенное подразделение (например, ИТ-отдел), но в случае ИСУП важно обеспечить наиболее быстрое реагирование на вопросы пользователей непосредственно из ПрОф. ИТ- подразделение, наверняка, не уступит (и не должно) функции по обеспечению безопасности данных, обеспечение бесперебойной работы программного продукта. Но что касается настройки и обучения – тут важно оставить эти функции внутри ПрОф. Особенно на старте внедрения КСУП необходимо, чтобы в организации был сотрудник, свободный от другой нагрузки, способный быстро и качественно найти и представить в нужном виде информацию из системы, организовать выгрузку нужных данных, настроить регулярный отчет, справочник и т.п. Все участники проекта и заинтересованные стороны так или иначе пользуются информацией о проекте, важно помочь им делать это более эффективно, быстро и удобно.
Основные функции администратора ИСУП:
- Предоставление доступа к информационному ресурсу (в соответствии с политикой безопасности);
- Настройка функционала системы;
- Обеспечение технической поддержки (первая линия);
- Проведение обучения по использованию;
- Взаимодействие с вендором для развития системы (обсуждение технических заданий на развитие функционала, устранение дефектов, установка обновлений и т.п.).
Для наиболее гибких систем выполнять функции администратора информационной системы может человек без специальной подготовки и знания программирования. Применимо совмещение этой функции с администратором проектов, тогда администратор становится главным помощником Руководителя проекта во всеоружии: выручает и знанием методологии управления, и предоставлением нужных функций информационной системы для управления проектом. Только в этом случае важно определить главного администратора (или архитектора), который сможет контролировать общие настройки: календари, объекты, права доступа и т.п.
3.3.5. Дополнительные роли
В зависимости от задач ПрОф, а также требований заинтересованных сторон возможно выделение других ролей. Если в компании ведутся сложные программы или существует несколько крупных портфелей (бизнесов) целесообразно выделить администраторов портфелей, которые обеспечат централизацию информации по проектам, представят топ-менеджерам нужные данные, организуют необходимые в рамках методологии коммуникации и принятие решений. Если компании важно строго контролировать ресурсы, то возможно выделение отдельного менеджера по ресурсам, который сможет отслеживать план по использованию ресурсов (например, бюджета), контролировать риски перерасхода, своевременно выявлять экономию и информировать о ее наличии, организовывать принятие согласованных решений о перераспределении ресурсов. Для многих компаний важной функцией ПрОф является умение расчета экономической целесообразности идей, а также отслеживание экономического эффекта для реализованных проектов. В развитых Проектных офисах, как правило, существует собственный тренер по проектному управлению, который регулярно организует учебные курсы и сертификацию для проектных команд, ведь команда проекта – временное объединение людей, для которых важно понимать используемые методы и уметь их применять.
3.4. Принципы построения эффективного Проектного офиса
Исходя из вышесказанного ПрОф – важное и незаменимое звено в процессе построения КСУП. Эффективная работа этого подразделения прямо сказывается на результатах проектов, а, значит, и достижении стратегических целей компании. Однако многие Проектные офисы умирают, так и не достигнув целей своего предназначения. Почему так происходит? В чем ошибки при организации этого подразделения и можно ли их избежать?
Посмотрим на проблему с позиции двух самых заинтересованных сторон (ролей) проектного управления и возможных заказчиков ПрОф: со стороны топ-менеджмента и со стороны Руководителя проекта и членов его команды.
Топ-менеджмент, прежде всего, ожидает от ПрОф возможности простого и быстрого понимания статуса управления. Например, своевременного обнаружения существующих рисков для возможности повлиять ни них. С другой стороны, топ-менеджмент ожидает трансляцию и исполнение корпоративных стандартов, чтобы управление проектами в организации было четким, слаженным, прогнозируемым. Если после завершения процесса внедрения КСУП у высшего руководства не появляется четкой картины, как управляются проекты, количество реализованных рисков не сокращается, нет понимания по принятым решениям, а от сотрудников поступают жалобы о трудно применимых процессах, которые тормозят получения важных результатов, – такой ПрОф будет не нужен, и топ-менеджмент никогда не будет его союзником.
Руководители проектов, со своей стороны, ожидают от ПрОф, во- первых, возможности для быстрого и качественного взаимодействия с руководством, например, приемлемое время для принятия согласованного решения по важному вопросу проекта. Во- вторых, Руководители проектов ждут от применяемой методологии усиление профессионализма управления, помощи при реализации проектов, улучшения взаимодействия с Заказчиками, командой и владельцами ресурсов. Например, понятные правила для выделения ресурсов или четкая работа по распространению важной информации у Заказчика. И если после внедрения КСУП управлять проектом стало только тяжелее, не появились инструменты для упрощения взаимодействия внутри и снаружи проекта, а топ- менеджмент не может правильно реагировать на существующие риски – руководители проектов никогда не оценят ни красивые документы, ни регалии сотрудников такого ПрОф, ни современную информационную систему, как бы она ни была хороша.
Такую картину можно изобразить на простой схеме:
Итак, как Проектному офису обеспечить обоюдовыгодное движение к потребностям этих двух ролей?
1. Правильно провести проект внедрения КСУП. Именно проект – с фиксацией целей, результатов, планом коммуникаций, реестром рисков и прочими приемами управления.
2. Выбрать правильную методологию и внедрять ее, обязательно пилотируя использование документов и методик.
3. Использовать информационную систему управления проектами в соответствии с уровнем зрелости проектного управления, сложностью проектов и компетенциями пользователей.
4. Разработать единую систему мотивации для Руководителей проектов/программ и сотрудников Корпоративного Проектного офиса.
5. Непрерывно совершенствовать процессы управления: анализировать применение практик проектного управления, убирать неиспользуемые и лишние инструменты и добавлять необходимые процедуры для поддержки проектов.
Ответы на некоторые из этих вопросов мы и постарались раскрыть в нашей книге.
Глава 4. Построение процессов проектного управления
4.1. Определение целей и результатов
4.1.1. Решение о проекте основано на целях компании
Определение целей и результатов проекта, его границ и условий происходит (и должно происходить) еще на прединвестиционной фазе. Тогда, когда решение о проекте еще только готовится. Уже тогда важнейшей работой Заказчика или инициатора проекта является четкая формулировка возможных выгод от проекта, определение значимых результатов, которые обеспечат достижений поставленных стратегических или тактических целей. Ведь решение о целесообразности проекта и выделении для его выполнения необходимых ресурсов должно строиться на четком осознании выгод проекта и сравнении этих выгод с другими предложениями (проектами). Именно конкуренция между целями проектов в связке с пониманием влияния проектов на выполнение задач топ-менеджмента может обеспечить лучший подбор объектов для инвестиций.
Одной из задач Проектного офиса может являться сбор проектных инициатив. То есть определение соответствия инициативы текущей стратегии, оценка вклада ее целей в плановые бизнес-показатели, группировка конкурирующих предложений и сравнение предложений с текущими выполняемыми проектами, предоставление данных по принятым уже решениям и прецедентам. Тогда ПрОф может не только показать, какие инициативы появились и как они связаны со стратегией, но и как они влияют или конкурируют с текущими проектами, проанализировать необходимые ресурсы, спрогнозировать возможные даты запуска таких инициатив, подсказать, как принимались решения по аналогичным инициативам ранее. Вот тогда ПрОф действительно предоставляет сервис по поддержке принятия решения и утверждению портфеля проектов, способствует более качественным и обоснованным решениям.
В этой книге мы не будем подробно затрагивать вопросы формирования портфеля проектов, но совсем не сказать об этом нельзя. Ориентация топ-менеджмента на выбранную стратегию, понимание измеримого вклада каждой инвестиции на пути к достижению целей – важнейшая работа по становлению действительно эффективного бизнеса и имеет огромное значение для проектного управления. Осознанный выбор проекта и его прозрачное влияние на цели бизнеса неизменно сработают для более правильных решений на этапе реализации проекта, для включения в работы проекта заинтересованных сторон, для правильного целевого использования полученных результатов.
Корректная формулировка целей и результатов проекта имеет огромное значение, прежде всего, в процессе формирования и согласования Устава. На эту работу наибольшее влияние оказывают три самых заинтересованных стороны проекта: Заказчик, Руководитель и Куратор.
Как взаимодействуют эти участники? В чем основной интерес каждого из них?
1. Куратор. Куратор отвечает за достижение стратегических целей, а, значит, ему важно использовать обещанные проектом бизнес-выгоды для их достижения. Кроме того, он распоряжается ресурсами или имеет влияние на их распределение. Исходя из вышесказанного Куратор, прежде всего, отвечает за соответствие проекта текущей стратегии и экономное выделение ресурсов для его выполнения. При согласовании Устава Куратор дает свое согласие, что цели проекта соответствуют утвержденным стратегическим и тактическим целям компании, и что необходимые проекту ресурсы действительно можно выделить в указанные сроки, не затронув интересы других проектов портфеля.
2. Заказчик. Именно Заказчик, чаще всего, является инициатором проекта, и именно он собирает доказательства необходимости проекта: обосновывает его выгоды, защищает перед руководством его целесообразность, готовит технико- экономическое обоснование (окупаемость). Тот, кто заказывает проект, отвечает перед Куратором за достижение бизнес-выгод проекта и за отдачу выделенных инвестиций (ресурсов). Получается, что Куратор выделяет необходимые ресурсы за то, что Заказчик обязуется вернуть их в виде выгод проекта.
3. Руководитель проекта. Руководитель проекта отвечает перед Заказчиком за поставку требуемых результатов, их качество и расходование выделенных ресурсов. То есть Заказчик должен четко определить требуемые результаты и сформулировать конкретные критерии их качества для гарантированной приемки. Изменение требований к результатам проекта лежит в зоне ответственности Заказчика, а просрочка поставки утвержденных результатов, перерасход бюджета или их несоответствие содержанию и описанным критериям качества
– в зоне ответственности Руководителя.
Кратко такое взаимодействие можно изобразить на схеме:
Как легко заметить из схемы, все взаимодействие построено исходя из достижения именно бизнес-целей компании (стратегических или тактических), а не конкретного Заказчика. Куратор утверждает цели проекта в соответствии именно с выполнением стратегии, Заказчик на основе утвержденных целей формулирует результаты и отвечает за достижение бизнес-выгод при их использовании, а Руководитель отвечает за поставку результатов в соответствии с требованиями Заказчика.
Ключевым моментом в управлении проектом является процесс создания и согласования Устава. Устав – это формально оформленный и утвержденный документ, который фиксирует единое понимание проекта для его основных сторон: Заказчика, Руководителя проекта и Куратора. Можно сказать, что Устав является внутренним контрактом, который защищает интересы этих трех сторон и формализует закрепление их ответственности:
- Куратора: выделить необходимые ресурсы;
- Заказчика: достичь бизнес-выгод (окупить выделенные ресурсы);
- Руководителя проекта: получить необходимые результаты.
Для системной работы по управлению проектами важно, чтобы документ был понятен, имел примеры заполнения и нес в себе юридическую силу. Устав может иметь единый шаблон для всех проектов компании или разные шаблоны для разных типов проектов. За поддержание актуальной версии шаблона Устава отвечает Проектный офис, он же, как правило, несет ответственность за то, чтобы заполненный документ соответствовал всем стандартам оформления в компании и был согласован со всеми необходимыми сторонами.
Основные разделы Устава:
- Суть проекта, причины его инициации;
- Цели проекта, их влияние на бизнес-цели компании;
- Основные результаты проекта и сроки их получения;
- Выделяемые ресурсы: финансовые, материальные, трудовые;
- Требуемый срок завершения всего проекта;
- Риски и допущения проекта;
- Основные ответственные стороны;
- Что-то другое важное, о чем стоит договориться «на берегу».
Основные согласующие стороны Устава:
- Заказчик проекта;
- Куратор проекта;
- Руководитель проекта;
- Ключевые участники (исполнители и пользователи результатов);
- Владельцы ресурсов (например, руководитель финансовой службы, функциональные руководители основных участников);
- Сотрудники, ответственные за контроль достижения целей проекта (например, за мониторинг выполнения бизнес-плана и других показателей проекта);
- Все, без чьей работы выполнение проекта или достижение его целей невозможно.
Многие компании используют не Устав, а стандартные контракты между Заказчиком и Поставщиком. Однако, это может навредить проекту, ведь контракт заключается, как правило, до его начала, а, значит, у Руководителя проекта просто нет возможности договориться о процессе его выполнения и конкретизировать нюансы проекта непосредственно с Заказчиком. Для профессиональных и просто опытных Руководителей проекта Устав является надежным обязательным инструментом согласования основных смыслов проекта. Умелое применение этого документа делает управление ориентированным на достижение целей и охрану интересов всех сторон. Для менее опытных Руководителей проекта это может быть грамотная поддержка управления, которая позволит избежать многих рисков и использовать корпоративный опыт. Например, нередко применяют «шаблоны» Устава для часто выполняемых проектов, в которых заранее прописаны основные договоренности, которые стоит согласовать с участниками.
4.1.3. Три шага определения проекта для достижения цели
Каждая организация использует свой вариант Устава, ведь стандарт четко не определяет рамки документа и не требует соблюдения заранее известной формы. Но для достижения цели проекта необходима правильная формулировка трех разделов этого документа:
1. Цель проекта: для изменения каких показателей бизнеса запущен проект, какое измеримое изменение необходимо и когда планируется получение выгод;
2. Результаты: что, когда и в каком размере (объеме) должно быть получено по итогам проекта;
3. Критерии успеха: на основании каких измерений можно оценить, что результаты соответствуют цели и способны достичь обещанных показателей.
Все три элемента должны быть связаны с друг другом, а корпоративная методология должна четко определять ответственность за выполнение и контроль каждого из них.
4.1.4. Правила определения целей
Главная задача правил формулировки целей – обеспечить прозрачность понимания, что именно, когда и на сколько должно измениться в компании после выполнения проекта.
Когда не стоит принимать решение о запуске проекта:
· Обоснование необходимости выполнения строится только на искусстве убеждения и красноречии Заказчика;
· Цель сформулирована общими словами: «повышение эффективности», «автоматизация», «оптимизация»,
«модернизация», «преимущества», «снижение рисков»;
· Проект не подкреплен объективными доказательствами необходимости (договорами, документами, независимыми оценками и т.д.);
· Нет понимания будущих изменений в цифрах.
Попробуйте использовать правила SMART для формулировки цели проекта, то есть цель должна быть: конкретной, измеримой, достижимой, реалистичной и ограниченной во времени. Такие же правила пригодятся для формулировки ваших стратегических целей, программ проектов и даже просто задач.
Критерии SMART:
· Specific (конкретные) – определите используемые в компании показатели, которые должны измениться после выполнения проекта (чистая прибыль, количество клиентов, снижение расходов на обслуживание, средняя оценка качества продукции и т.п.);
· Measurable (измеримые) – определите, на сколько и по какой шкале должен измениться показатель, кто может его замерить, есть ли инструмент для измерения, нужно ли их создавать в проекте;
· Attainable (достижимые) – сформулируйте, за счет чего планируется достигнуть цели, какие результаты планируется получить;
· Realistic (реалистичные) – убедитесь, что выполнение проекта позволит достичь желаемой цели, опишите альтернативы;
· Time-bounded (ограниченные сроки) – определите период по наступлению/окончанию которого должна быть достигнута цель. Цель может звучать как «к ДД.ММ.ГГГГ» или «в течение квартала после завершения проекта» или «на момент завершения проекта» или «в течение года после запуска оборудования» и т.д.
Важно не просто декларировать правила формулировки цели, а требовать их выполнения. Все понимают, что Руководители проектов редко перечитывают регламенты и правила (возможно, только после совершения грубых ошибок и последующего наказания), гораздо эффективнее определить действительную ответственность за контроль соблюдения корпоративных правил и дать реальные полномочия выполнять такой контроль. Как правило, для проектного управления такая ответственность лежит на Проектном офисе. Например, при согласовании Устава ПрОф подтверждает, что цель соответствует правилам целеполагания и не согласовывает, если эти правила нарушены. Отсутствие факта согласования Устава должно гарантировать, что ресурсы для выполнения проекта не будут выделены, а работы начаты. Тогда не будет дан старт проектам с непрозрачными выгодами, а ресурсы не будут растрачиваться на непонятные цели. Как минимум, финансирование проекта или заключение контрактов с подрядчиками должно быть доступным только после согласования Устава.
4.1.5. Как договариваться о результатах
В зависимости от компетенции, опыта, взглядов, выгоды Заказчика или Руководителя проекта, каждый из них будет понимать продукт (или результат) проекта по-своему. Это мина замедленного действия, которая ожидает завершения работ. А в момент завершения могут выявиться скрытые требования к результатам, обнаружиться разное понимание одних и тех же формулировок, что может привести к задержкам завершения работ, переделкам, трате дополнительных ресурсов и разного рода другим конфликтам. К сожалению, совсем избежать таких конфликтов не получится, но сократить их, уменьшить риск их возникновения можно, если формулировать результаты правильно.
Недостаточно сформулировать результаты общими словами:
«внедренная система», «готовое здание», «заключенный контракт»,
«доставленный груз».
Даже в таком верхнеуровневом документе, как Устав, формулировка результатов должна быть конкретной и прозрачной для понимания всех заинтересованных сторон. И это должно быть объективно.
Что для этого стоит предусмотреть:
1. Выделить отдельный раздел Устава с описанием ключевых результатов:
- определение конкретных артефактов (документов, материалов, результатов) и их статуса;
- установка правил приема и передачи;
- назначение ответственных за подготовку и приемку.
2. Описать правила формулировки результата. Например, всегда формулировать результат: что должно появиться, где, совершенный вид, прошедшее число. Эффективнее прописать правила непосредственно в форме Устава, чтобы при заполнении Руководитель проекта и Заказчик могли увидеть правила и их применять.
3. Определить рамки для снижения рисков заинтересованности. Например, зафиксировать, что ответственным за приемку результата не может быть подчиненный Руководителя проекта или, тем более, сам руководитель. Или жестко прописать, что ответственным может быть только владелец продукта или Заказчик.
4. Прописать полномочия ПрОф для контроля соблюдения правил и утвердить их на уровне формального документа (Приказа, Положения и т.п.).
5. Провести учебный курс для Руководителей проектов, где выработать навык корректной формулировки целей и результатов. И объяснить им риски некорректной формулировки, чтобы снизить сопротивление.
Примеры корректной формулировки результатов:
Результат |
Правила приемки |
Ответственный |
|||
В организации внедрена система управления клиентами (CRM) |
Не менее трех филиалов подтвердили промышленную эксплуатацию системы (система регулярно используется, критичных ошибок нет). |
Директор по продажам |
|
||
Запущена рекламная кампания |
Рекламный блок на тему нового продукта запущен не менее, чем на трех радиостанциях, сайте компании и Instagram |
Руководитель отдела продаж |
|
||
Здание сдано в эксплуатацию |
Заказчик подписал акт приемки в соответствии со СНиП |
Заказчик |
|
4.1.6. Включение мотивации на результат
Мы уже говорили о том, чем отличается ответственность Руководителя и Заказчика проекта. Руководитель проекта отвечает за результаты и их качество, а Заказчик – за использование результатов и получение бизнес-выгод. Для того, чтобы корректно мотивировать команду проекта, нужно строго разграничивать эту ответственность и определять мотивацию каждой роли.
Наиболее простой вариант, когда Руководитель проекта сам же и является Заказчиком его результатов. Тогда вся работа проекта целостная, Руководитель и Заказчик в одном лице стремятся к получению бизнес-выгод и рассматривают этапы получения основных материальных результатов как промежуточные вехи на пути к главной цели.
Например, на производстве решили запустить новую линию. Очень часто Руководителем проекта по запуску такой линии является в будущем руководителем этого производства. Он будет главным образом мотивирован только прибылью по итогам запуска. Заранее можно оговориться, что совмещение роли Заказчика и Руководителя проекта не является предпочтительным, так как в этом случае устраняется основной конфликт выполнения качества и соблюдения ограничений, которые необходимы проекту. Но для единой мотивации этих ролей на цели проекта это наиболее простой случай.
Совсем другая ситуация возникает в проектах, в которых есть выделенный Руководитель проекта, задача которого предоставить Заказчику все необходимые результаты. При этом он не может отвечать за бизнес-выгоды, поскольку ответственность за использование этих результатов и управление ими лежит на Заказчике. В качестве примера можно привести ИТ-проекты, в которых, как правило, есть подрядчик, организующий внедрение программного продукта и не отвечающий за достижение бизнес- выгод с его помощью.
Как же определить мотивацию такого Руководителя так, чтобы и он был ориентирован на бизнес-выгоды проекта? Для этого можно включать в Устав критерии, которые могут определять степень успешности проекта по его результатам – в этой книге будем называть их Критерии успеха проекта.
Итак, что же такое критерий успеха и как его определить?
1. Критерий должен отражать результат, то есть соответствовать ему. Например, если конечный результат проекта – это внедренный программный продукт для поддержки продаж, его критерием не может быть успешное выполнение месячного плана продаж. Программный продукт не отвечает за выполнение плана.
2. Критерий должен содержать в себе проверку качества результата. Чтобы выполнение критерия говорило о том, что продукт сделан так, как понравится Заказчику. Если говорить о программном продукте, то критерии качества могут быть построены на количестве обращений в техническую поддержку, зарегистрированном числе дефектов. Скорость работы программного продукта и перечисление его функций не могут являться критериями качества – это обязательные требования, без которых продукт не может быть принят.
3. За выполнение критерия назначено материальное вознаграждение команды проекта или Руководителя проекта. При этом вознаграждение должно быть ценным, способным мотивировать. Например, для внутренних проектов считается, что доход менее, чем 15% от текущего дохода сотрудника не является мотивирующим.
4. Если критериев несколько, должно быть определено, как делится премиальное вознаграждение (премия за результат). Например, для каждого критерия определяется доля из премиального фонда проекта.
5. Нужно иметь возможность проверить критерий при завершении проекта. Если мы инициировали проект по строительству многоэтажного дома с возможностью удачно распродать площади и окупить инвестиции, то при сдаче дома мы не можем требовать от Руководителя проекта окупаемости инвестиций. В данном случае мы должны говорить о качестве строительства или можно включить в проект работу по запуску рекламной кампании для продаж.
6. Критерий должен быть интересен Заказчику проекта, и он готов платить за выполнение критерия.
7. Критерий должен быть выполним Руководителем проекта. Он готов терять существенный бонус, если не выполнит его. То есть он должен оценить критерий на выполнимость и понимать свою ответственность за него.
Основные подходы к формулировке критериев успеха:
1. Критерии успеха формулирует Заказчик проекта и согласовывает с Руководителем проекта.
2. Критерии отвечают на вопрос: как я (Заказчик) пойму, что этот продукт сделан хорошо?
3. Наиболее весомый критерий должен отражать главный результат или выгоду проекта.
4. Премиальный фонд за выполнение критериев успеха определен на старте проекта и зафиксирован в Уставе.
5. За выполнение критериев каждый исполнитель получает не менее 15% от текущего дохода.
6. Критериев успеха не должно быть более пяти.
Результат |
Критерий успеха |
В организации внедрена система управления взаимоотношениями с клиентами (CRM). |
За период опытной эксплуатации системы зарегистрировано не более трех критичных замечаний от пользователей. За период опытной эксплуатации простой системы составил не более двух часов. |
Запущена рекламная кампания. |
За первые 2 недели работы рекламной кампании зарегистрировано не менее 15 заявок на поставку. |
Здание сдано в эксплуатацию. |
Комиссия оценила комфорт в среднем не менее чем на 8 баллов из 10 по параметрам: чистота окон чистота подъездов скорость лифтов комфорт паркинга |
Если в каждом проекте вы четко определите критерии успеха по приведенным правилам, команде проекта будет проще ориентироваться на цели проекта, качество результатов и удовлетворенность Заказчика. Заказчик будет более удовлетворен, результаты будут отвечать бизнес-выгодам. А, значит, и бизнес- выгоды будут более вероятны, и достижение целей компании будет быстрее и успешнее.
4.1.7. Шаги для старта управления по целям
· Утвердите правила формулировки цели по SMART.
· Утвердите правила формулировки результатов и критериев успеха.
· Разработайте шаблон Устава проекта и снабдите его простой инструкцией по заполнению.
· Определите ответственность Проектного офиса за соблюдение корпоративных стандартов оформления Устава и его согласования.
· Проведите обучение Заказчиков и Руководителей проектов.
· Наделите полномочиями Проектный офис не допускать к рассмотрению проекты с нарушением установленных правил.
4.2. Управление проектами по контрольным точкам
4.2.1. Почему планирование по-старому не работает?
При традиционном подходе к планированию работ проекта план фиксирует работы, которые требуется выполнить. Соответственно контроль такого плана состоит в сборе отчетности по этим работам.
Руководитель проекта, Заказчик и Куратор для понимания статуса проекта вынуждены погружаться в организацию исполнения, изучение отчетности и даже выполнение отдельных работ. Соответственно, на управление такими проектами уходит много сил, и при этом сроки и содержание проекта все равно часто отклоняются от плановых значений. Со стороны исполнителей работ вмешательство руководства и Заказчика в выполнение работы в большинстве случаев встречается негативом, ростом конфликтов и снижением мотивации.
4.2.2. Какова суть метода контрольных точек?
Основная идея метода состоит в том, что вместо контроля процесса исполнения проекта Руководство компании концентрируется на контроле своевременной поставки ключевых результатов. Таким образом, в фокусе всегда остается требуемый результат, успешность выполнения оценивается на основании отклонения сроков его получения, а его приемка качества делегируется квалифицированному специалисту или непосредственно оценивается Заказчиком.
При таком подходе отчетность для Руководства максимально прозрачна и не требует изучения лишней информации. Контроль получения плановых результатов дает понимание движения проекта и не позволяет откладывать проблемы «на потом». Для Руководителей проектов и исполнителей работ такой подход гарантирует политику невмешательства в непосредственные работы и четкое понимание в необходимой отчетности.
Метод контрольных точек позволяет:
· планировать в категории «результатов»;
· не испытывать иллюзий «поднажмем-успеем»;
· разделить контроль на несколько уровней и минимизировать лишнее вмешательство в руководство работами.
4.2.3. Какие шаги должно сделать Руководство для применения метода?ШАГ 1. Определить конкретные поставко-ориентированные результаты (далее – Продукты проекта), которые должны быть сформированы или произведены проектом и требуемые сроки их поставки. При этом срок поставки действительно должен быть важен и обоснован.
Продукты – конечные конкретные измеримые результаты проекта, полученные в ходе выполнения работ и передаваемые заказчику.
ШАГ 2. Согласовать срок с исполнителями, определить их ответственность за подготовку результатов именно к этому сроку. Не должно быть двоякого понимания срока или ответственности: конкретная дата, один ответственный, один измеримый результат.
ШАГ 3. Определить того, кто может подтвердить, что результат получен, измерен, его качество соответствует заявленному, и его можно применить для достижения ваших целей или для целей проекта (Приемщиков).
ШАГ 4. Определить того, кто независимо может контролировать выполнения контрольных точек и правила контроля.
Такой же подход может распространяться и на Руководителя проекта, и на руководителей отдельных блоков работ. На основании понимания Продуктов проекта и требуемых сроков их поставки Руководитель проекта определяет требуемые промежуточные результаты (подпродукты), а также разрабатывает видение требуемых сроков их получения. Определяются исполнители и приемщики результатов. Таким образом, продуктовая декомпозиция может спуститься до уровня небольших групп и охватить все промежуточные результаты, которые требуют контроля. Общий вид декомпозиции продуктов проекта представлен на рисунке 4.
Рис. 4. Декомпозиция продуктов проекта
4.2.4. Что такое контрольная точка?
Контрольная точка (КТ) — это конкретный проверяемый результат проекта, который должен появиться в установленный срок.
КТ фиксирует:
· срок – когда должен быть получен результат;
· ответственного – кто ответственен за его получение;
· приемщика – кто подтвердит, что результат соответствует требованиям к нему, и его можно применить для целей проекта.
Сам результат контрольной точки должен иметь формулировку завершенного дела и однозначно определять результат, то есть по правилам русского языка должны использоваться:
· прошедшее время;
· совершенный вид;
· страдательный залог (отвечать на вопрос «Что сделано?»).
Например, не «Тестирование продукта», а «Тестирование продукта завершено». Ведь тогда стремиться нужно будет не к процессу «Тестирование продукта», а к завершению тестирования.
Для КТ должны быть зафиксированы измерения результата – инструменты, документы, показатели, на основании которых можно говорить о том, что результат действительно получен.
|
Результат |
Срок |
Ответственны й |
Приемщик |
1 |
Заключен контракт с поставщиком .... |
01.10.2017 |
Иванов А.Ю. |
Воскресенская С.М. |
2 |
Поставлено оборудование для монтажа |
09.08.2017 |
Галикбаров Р.С. |
Шубин П.Л. |
3 |
Запущена пилотная линия производства ... |
10.02.2018 |
Сафин М.Б. |
Верховой В.В. |
4.2.5. Какими бывают контрольные точки?
Конкретные результаты, которые формулируются для контрольных точек, могут быть совершенно разного уровня: от завершения согласования рабочего документа до заключения миллионного контракта. В зависимости от уровня результатов можно выделить несколько уровней контрольных точек.
Уровень 0. Вехи
Отдельно выделяют КТ, результаты которых критически важны для продолжения работы над проектом. Например, заключение контрактов с основными поставщиками, получение результатов исследований, на основании которых будут продолжены или остановлены работы, факты поставки по внешним контрактам, приемка в эксплуатацию ключевых продуктов.
Контроль таких результатов выполняет сотрудник высокого уровня (Генеральный директор, заместитель Генерального директора) или специальное подразделение (Проектный офис). При достижении вехи для руководства компании делается демонстрация результата и на ее основе выносится вопрос о продолжении или остановке проекта.
Уровень 1. Критические
Следующий уровень КТ – это промежуточные результаты и события, которые критически важны для Заказчика проекта. На этом уровне могут находиться результаты, приемку которых производит непосредственно Заказчик (отбор поставщиков, принятие решений по разработкам, приемка дизайнов и прототипов и т.п.), или события, срок наступления которых является критичным с экономической точки зрения (конкурентная борьба, требования законодательства, сезонные события, условия рынка и т.п.).
Как и для вех, контроль получения этих результатов выполняется на высоком уровне. Отклонение сроков достижения таких результатов рассматривается Первым лицом или специальным органом – Проектным комитетом. А при достижении результатов Руководитель проекта обязан привлечь Заказчика к приемке или представить ему полученные результаты.
Уровень 2. Ключевые
Еще на уровень ниже могут быть зафиксированы промежуточные результаты, необходимые для получения критических результатов. Например, завершение подготовки конкурсных процедур, завершение разработки отдельных элементов, создание отдельных макетов.
Как правило, такие контрольные точки зафиксированы базовым планом работ, который утверждается для проекта и контролируется Проектным офисом. Именно базовый план является рабочим документом Руководителя проекта, а на основании его отклонений Проектный офис может определять риски отклонения контрольных точек более высокого уровня и своевременно предупредить заинтересованных сторон.
Уровень 3. Оперативные
На нижних уровнях могут располагаться оперативные результаты. Результаты, которые определил Руководитель проекта в рамка ежедневных, еженедельных планов – завершение разработки какого-то модуля, согласование документа, наладка конкретного механизма. Для масштабных проектов такие контрольные точки помогают Руководителю проекта сконцентрироваться на управлении результатами и экономить время на управлении.
Могут быть и более низкие уровни – все зависит от масштаба проекта, размера команды, числа результатов, которые можно и нужно контролировать.
Общее представление планирования контрольных точек представлено на рисунке 5.
Рис. 5. Планирование по контрольным точкам
Разделение уровней позволит каждому руководителю сосредоточиться на контроле действительно важного дня него результата, не погружаться в тонкости более низкого управления. Для исполнителей работ разделение на уровни гарантирует политику невмешательства в ход работ до момента сдачи плановых результатов, что предоставляет определенную свободу действий, а не расстрельный контроль за каждый неверный шаг.
На каждом уровне контрольные точки должны быть формально утверждены.
Утверждение предполагает:
· Документ несет в себе силу, которую принимает и руководитель, и исполнитель.
· Все заинтересованные стороны имеют доступ к утвержденному документу.
· Пересмотр контрольных точек выполняет тот же орган, который их утвердил.
На верхнем уровне утверждение будет выполнено через Устав или приказ, который утверждает первое лицо или председатель Проектного комитета. На нижнем – это может быть документ в MS Excel или MS Word, который согласовали участники команды, или даже цветные кнопки на доске, которую видит конкретный отдел.
|
Вопрос |
Ответ |
1 |
Кто должен сформулировать КТ высокого уровня? |
Контрольные точки 0 и 1 уровня ответственен сформулировать Заказчик проекта. Если у Заказчика нет требований к срокам кроме финального срока передачи результата, значит Руководитель проекта ответственен за определение КТ своего уровня и контроль проекта будет осуществляться только на основе Базового плана. |
2 |
Могут ли сроки КТ быть жестко спущены сверху? Как производится их планирование? |
Для КТ высокого уровня так и бывает в большинстве случаев. Есть заранее определенные условия получения результатов или, как минимум, срок завершения проекта. При подписании Устава Руководитель проекта дает свое согласование этих сроков. Таким образом, КТ высокого уровня планируются «на бумаге», без использования ИСУП. |
3 |
А что делать РП, если топ просит сделать в два раза быстрее? Как обосновывать свою позицию? |
Руководитель проекта может обосновать отказ от исполнения срока на основании архива проектов (если он есть) или построить Базовый план с обоснованными сроками, из которого логично просматриваются промежуточные |
|
|
результаты, которые требуется получить в |
|
|
проекте. Также можно поднять вопросы |
|
|
качества и зафиксировать уровень качества |
|
|
в Уставе, если ради сокращения срока он |
|
|
сильно снижен. |
4 |
Как Руководителю проекта согласовать |
В случае отказа функциональных руководителей выполнять сроки |
|
«навязанный» сверху план по срокам с |
контрольных точек более низких уровней выполняется эскалация на Куратора |
|
функциональными подразделениями? Ему это делать в ИСУП или на бумаге? |
проекта, ищутся альтернативы (в том числе, со снижением качества), или производится запрос на корректировку сроков КТ более высокого уровня. Разработка планов после подписания Устава производится только в ИСУП. |
5 |
Сколько уровней КТ должно быть? |
Количество уровней КТ зависит и от зрелости компании, и от масштаба проекта. На первых шагах применения метода в компании мы рекомендуем использовать не более 2 уровней КТ: КТ в Уставе (вехи и критические результаты) и Базовом плане. Если компания зрелая и выстроила культуру управления по контрольным точкам, то последний уровень КТ устанавливается для рабочей группы не более 5 человек, и срок получения промежуточных результатов не должен превышать 2 недели. |
Базовый план – согласованный с заинтересованными сторонами и утвержденный к реализации перечень результатов со сроками их приемки.
4.2.7. Кейс крупного банка
Председатель Правления поставил задачу «Создать первый в мире мобильный банк на технологии блокчейн».
Для контроля исполнения проекта были разработаны следующие контрольные результаты:
Через месяц Руководству были представлены итоги конкурса по выбору поставщиков и заключен контракт на работы. Поскольку согласования условия контракта были затянуты, контрольная точка по согласованию дизайна не была выполнена в срок, что отразилось на премировании участников проекта. Зато следующий результат – «Запущены в пилотном режиме 5 страниц нового сайта» – был представлен ранее срока и получил высокую оценку.
4.3. Регулярная отчетность как основной инструмент управления
Применение метода контрольных точек не означает, что от результата к результату проект является черным ящиком. Отсутствие отчетности по проекту несет в себе всем известные риски:
· нет понимания статуса – текущего положения проекта относительно его планов;
· нет понимания движения по проекту, важно своевременно информировать заинтересованные стороны о достижениях, даже небольших;
· нет понимания возникающих проблем и рисков.
Обратная ситуация – избыточная отчетность занимает слишком много времени у ее составителей и потребителей. Даже при использовании современных систем управления проектами избыток таблиц, диаграмм и индикаторов значительно усложняет работу с проектом и для руководства, и для исполнителей.
В системе, ориентированной на результат, регулярная отчетность является основным инструментом управления. Основной задачей КСУП является баланс отчетности, которая, в свою очередь, поддерживает потребность в информации, но содержит только необходимые данные для своевременного реагирования на отклонения.
Какие отчеты нужны?
Отчетность строится в соответствии с уровнями контрольных точек – для Первого лица, для Куратора и Топ-менеджмента, для Руководителя проекта и т.д. Последний уровень отчетов строится по задачам проекта для понимания процесса. Этот уровень отчетности используется Руководителем проекта для организации исполнения и быстрого обмена информацией.
8 Куратор – лицо, отвечающее за показатели деятельности, на которые влияют бизнес-цели проекта. Куратор ответственен за обеспечение проекта ресурсами, осуществляет административную, финансовую и иную поддержку проекта, а также обладает достаточными полномочиями для решения указанных вопросов.
Конечно, виды отчетов, которые требуются организации могут быть различными, охватывающими все группы процессов управления проектами. Но мы выделим отчетность, которая ориентирована на решение самой большой проблемы при выполнении проектов и задач – срыв сроков получения результатов.
4.3.2. Отчеты для Руководства
Для проектирования отчетов Руководству важно соблюсти меру – отчетов не должно быть много и каждый отчет не должен быть слишком объемным.
Основными отчетами для Руководства являются:
· Отчет о статусе проекта;
· Диаграммы контрольных точек;
· Прогнозы выполнения контрольных точек;
· Отчет по контролю бюджета портфеля.
1. Статус проекта – важнейший отчет для быстрого понимания текущего состояния проекта. Для этого отчета важно определить требования к информации о проекте и разработать короткую форму для отражения информации, в идеале – формат А4.
Основная информация, требуемая в этом отчете:
Краткая информация о проекте – Заказчик, Руководитель проекта, сроки выполнения, бюджет;
Перечень утвержденных контрольных точек и зафиксированные отклонения;
Существующие риски и прогнозы отклонения контрольных точек;
Последние решения по проекту;
Важные данные по проекту по запросу Руководства.
Пример такого отчета представлен на рисунке 6.
Рис. 6. Отчет о статусе проекта
2. Диаграмма контрольных точек – карта проектов с отметкой плановых результатов и статуса их получения. В данном случае, на основании метода контрольных точек Руководство видит только два состояния результата – получен/не получен.
Такая диаграмма может быть разработана в сводном виде – например, у Топ-менеджера есть программа проектов, и он хочет понимать в один клик текущие и плановые результаты.
Сводная диаграмма представлена на рисунке 7.
Рис. 7. Сводная диаграмма КТ
Если руководство рассматривает конкретный важный проект, то диаграмма может показать достижения результатов по этому проекту, а также ближайшие плановые результаты.
Пример диаграммы одного проекта на рисунке 8.
Рис. 8. Диаграмма КТ одного проекта
3. Отчет по прогнозам выполнения контрольных точек – отчет, показывающий наиболее вероятную, по мнению Руководителя проекта, дату получения плановых результатов, а также существующие риски их получения. Не вмешиваясь в управление проектом, Руководство понимает, какие есть прогнозы, проблемы или возможности для получения результатов и может своевременно подключиться для устранения проблем или использования возможностей.
Пример отчета представлен на рисунке 9.
Рис. 9. Прогнозы и риски выполнения КТ
4. Отчет для контроля превышения бюджета – для Руководства важно регулярно (например, раз в квартал) делать представление по степени расходования средств проектов.
Не секрет, что бюджет проекта может несколько раз корректироваться – возникают дополнительные требования, принимаются решения о важных дополнениях и изменениях, на бюджет могут влиять внешние факторы. Руководство не может удерживать во внимании, насколько бюджет проекта скорректирован, и является ли это угрозой для выполнения других задач. Именно для достижения целей организации необходимо регулярно выявлять критичные отклонения бюджета.
В этом случае обязанность Проектного офиса регулярно предоставлять отчет с индикатором критического превышения бюджета. Как правило, на основании такого отчета могут приниматься решения о корректировке содержания проекта, снижение требований к качеству или остановке каких-то проектов.
Пример такого отчета представлен на рисунке 10.
Рис. 10. Отклонение расходования бюджета по программе проектов
Какие дополнительные отчеты нужны Руководителю:
· Отчет о статусе задач;
· Отчет по выполнению задач;
· Бюджет доходов и расходов по статьям.
1. Отчет о статусе задач – это основной отчет проекта. Он – как маленький кирпичик большого здания. С регулярным сбором и пониманием статуса исполнения задач строится регулярная отчетность исполнения всего проекта. Каждая задача назначена конкретному исполнителю, и задача Руководителя проекта – регулярно понимать, насколько она выполнена. Хорошей практикой считается правило еженедельной актуализации статуса задач: все исполнители, например, по пятницам актуализируют статус своих задач, то есть отмечают, выполняется ли задача и какая доля задачи выполнена.
Пример задач с заполненным статусом представлен на рисунке 11.
Рис. 11. Иерархическая структура работ и статусы задач
2. Отчет по исполнению задач – это текстовые отчеты, которые, как правило, никто не любит. Но именно эти отчеты содержат в себе самую ценную информацию для руководителя проекта – что сделано, и что предстоит сделать по задаче.
Если Руководитель проекта работает в непосредственной близости от команды, такие отчеты излишни. Но если команда распределена, есть удаленные сотрудники, или у Руководителя проекта на контроле два, три, пять проектов – такие отчеты необходимы.
Текстовый отчет по одной задаче, срок исполнения которой не превышает двух недель, как правило, краткий и состоит из двух блоков:
· «Что сделано?» – кто, когда, и какой результат получил.
· «Что предстоит сделать?» – кто, к какому сроку, и что конкретно должен сделать.
Анализировать отчет становится простой задачей. Исчезает необходимость просмотра переписки, анализа переданных документов, дополнительного запроса сроков и т.д. А из поля «Что предстоит?» автоматически могут быть сформированы задачи проекта на следующий отчетный период для контроля их выполнения.
Пример отчета представлен на рисунке 12.
Рис. 12. Отчет по выполнению задач
3. Бюджет доходов и расходов по статьям – классический отчет для управления финансами. Этот отчет используют как финансисты предприятий, так и Руководители проекта. Данный отчет является ежедневным инструментом контроля поступления и расходования средств и позволяет руководителю проекта своевременно устранить риски превышения бюджета. Основная сложность использования такого отчета – обеспечить связь между системой учета транзакций (бухгалтерией) и системой управления проектом (ИСУП).
Пример отчета представлен на рисунке 13.
Рис. 13. Бюджет доходов и расходов по статьям
4.3.4. Как организовать эффективный процесс сбора достоверной отчетности?
Конечно, если работ в проекте много, есть более четырех уровней контрольных точек – возникает сложность сбора отчетности: затрачивается много времени для рассылки запросов, напоминания о необходимости заполнить формы, анализа результатов и т.п. Сбор отчетности может стать большой проблемой и не нести уже пользы для проекта, если ко времени получения отчета информация в нем устаревает.
Для решения этой проблемы используют информационную систему управления проектами, и не просто используют ее для хранения отчета. ИСУП должна и может сама организовывать процесс сбора отчетности и обработки.
Представьте себе, что еженедельно участники проекта видят приглашение к заполнению отчета. Заполнить отчет – значит, ответить на два-три простых вопроса: описать кратко проделанную и плановую работу, определить прогнозы получения результатов и существующие риски. Заполненные данные автоматически попадают в отчеты для заинтересованных сторон.
Пример такой формы представлен на рисунке 14.
Рис. 14. Форма сбора отчетности по выполнению задач
Руководитель проекта, со своей стороны, имеет монитор для отслеживания нарушений и может решить единичные вопросы лично.
|
Вопрос |
Ответ |
1 |
Как заставить Руководство смотреть отчетность по проектам? |
Отчетность по проектам для Руководства, если Руководство не является прямым Заказчиком проекта, должна представляться на специальном комитете, в обязанности которого входит контроль за выполнением проектов. Ответственность за подготовку такой отчетности лежит на Проектном офисе. |
2 |
Должно ли Руководство работать в информационной системе? |
Такой обязанности нет – иногда руководство готово использовать современные технологии, а иногда нет. Но необходимо, чтобы любая отчетность, сформированная для руководства, была получена на основании ИСУП. |
3 |
Что делать, если исполнители задач отказываются заполнять отчеты в системе, но присылают отчеты «по старинке» на почту? |
Проектный офис с помощью ИСУП должен регулярно формировать отчеты о дисциплине по предоставлению отчетности. Нарушения дисциплины должны приравниваться к неисполнению должностных обязанностей. |
4 |
Можно ли избавить исполнителей от заполнения отчетов, если Руководитель проекта все время с ними контактирует и не нуждается в этих отчетах? |
Конечно, но в этом случае Проектному офису нужно организовать аналогичный сбор краткой информации по исполнению проектов. В этом случае на еженедельной основе Руководители проектов будут фиксировать полученные результаты и планы на будущий период. Такой отчет будет полезен как Заказчикам проектов, так и самим руководителям, чтобы структурировать свою работу. |
5 |
Сколько времени должно занимать предоставление отчетности у Руководителя проекта? |
Если говорить о рекомендуемом минимуме, который мы описали, то на каждый проект у руководителя проекта будет уходить 10 минут в неделю. В отчет войдет определение прогнозов и рисков по контрольным точкам верхнего уровня и краткое описание проделанной работы и планов на следующий период. |
4.4. Эффективные коммуникации в короткие сроки
4.4.1. «Посидели, поговорили, разошлись…»
Для многих руководителей, в том числе и руководителей проектов, камнем преткновения является неумение проводить эффективные совещания. Чаще всего, совещания рассматриваются как потеря времени: в них часто участвуют сотрудники, которые не имеют никакого отношения к вопросам совещания, обсуждение не имеет четких границ, по итогам решения не фиксируются. Даже если решения принимаются, никто не отслеживает их выполнение. Для проектов потеря времени губительна, именно поэтому одним из первых шагов в построении КСУП является организация эффективных и коротких совещаний.
4.4.2. Коммуникации с Заказчиком
Еще при согласовании базового плана проекта Руководитель проекта должен поднять вопрос о выделении Заказчиком времени для регулярных коммуникаций по проекту. Как правило, в ходе работ найдутся тысячи причин для отмены коммуникаций – накладки по другим встречам, несвоевременная договоренность, пропущенное приглашение и т.п. В идеале для этой коммуникации должны быть согласованы формы предоставления информации, требуемая отчетность, каналы доставки и многое другое.
ШАГ 1. Планирование коммуникаций.
Если мы говорим о первых шагах становления управления проектами, как минимум, нужно обеспечить установку правил для регулярных встреч с Заказчиком проекта:
· по каким дням недели доступен Заказчик;
· в какое время и сколько по продолжительности будет встреча;
· очно или удаленно он сможет участвовать;
· каким образом Руководитель проекта будет передавать Заказчику повестку.
Проектный офис должен проконтролировать, что такой документ согласован, а после согласования этого документа в корпоративный календарь должны быть внесены все встречи по проекту, и приглашены все участники. Тогда Заказчику всегда будет заранее известно о необходимости присутствовать на встрече, а перенос потребует уведомления Руководителя проекта.
Шаг 2. Проведение коммуникаций на основе данных ИСУП.
Регулярные коммуникации с Заказчиком должны основываться на отчетности ИСУП, например, диаграмме контрольных точек. Тогда перед глазами всегда будут плановые результаты и их сроки, полученные результаты или их отклонения. Сама повестка встречи для Заказчика может основываться на:
· информировании о статусе получения результатов (какие получены, какие в стадии приемки, что предстоит получить в ближайшее время);
· информировании о текущих рисках и проблемах, фиксации следующих шагов для разрешения проблем (определения требуемых экспертов, назначение задач для анализа, согласование времени для проведения совещаний и решения проблем);
· информирование о принятых решениях;
· сбор предложений и пожеланий или согласование времени для проведения таких совещаний.
В ходе обсуждения Руководитель проекта может демонстрировать диаграмму Ганта, отчеты по прогнозам или последние принятые решения в отчете о статусе проекта. В этом случае Руководитель проекта подкрепляет свою информацию данными системы.
ШАГ 3. Фиксация протоколов.
Решения обязательно должны фиксироваться. В идеале такой протокол должен храниться в корпоративном календаре. Еще лучше, если и повестка совещания, и все документы, которые требуются для его проведения, и протокол с результатами и решениями, хранятся в ИСУП.
4.4.3. Коммуникации Руководителя проекта с командой
Коммуникации Руководителя проекта с командой не менее важны, чем с Заказчиком, и должны организовываться с помощью тех же шагов: планироваться, выполняться на основе данных информационной системы и протоколироваться.
Для коммуникаций с командой важно не только регулярно понимать статус выполнения задач и определять риски (это можно делать и с помощью отчетных форм), важно распространять нужную информацию среди участников для единого понимания статуса проекта. Также очень важно развивать команду – создавать командную атмосферу, поздравлять людей с днем рождения или с выздоровлением после болезни, благодарить за своевременно или качественно выполненные задачи. Несмотря на то, что о последних целях коммуникаций все догадываются, Руководители проектов редко являются настолько зрелыми, чтобы включать эти вопросы в свои совещания – именно поэтому это является задачей КСУП.
Кроме того, важно организовать коммуникации в максимально короткие сроки, ведь для проекта ценно, в первую очередь, то время, которое тратится на выполнение его задач. Время для такой коммуникации должно быть необременительным для участников и может составлять не более 15 минут.
Типовая повестка совещания с командой проекта:
· статус проекта (какие контрольные точки выполнены, какие в процессе приемки, какая следующая);
· риски и проблемы проекта – Руководитель проекта озвучивает результаты отчета или опрашивает участников о том, какие риски им известны;
· принятые решения – Руководитель проекта информирует о том, какие решения приняты относительно проекта руководством, какие новые требования предоставлены Заказчиком, и сразу согласовывает участников, время и продолжительность совещания для их обсуждения;
· благодарности и поздравления.
4.4.4. Как проводить совещания с командой проекта за 15 минут?
Для организации регулярных коротких коммуникаций можно дать несколько эффективных рекомендаций.
В первую очередь, важно определить цель коммуникации и донести ее до всех участников. Если тема вопроса не соответствует цели – лучше исключить вопрос из обсуждения и назначить для его обсуждения отдельное время.
Целями могут быть:
· единое понимание командой проекта статуса, проблем и рисков;
· единое понимание следующих шагов;
· доведение особо важной/срочной информации;
· согласование состава участников, даты и продолжительности требуемых совещаний;
· укрепление команды.
· Целью не должно являться:
· выработка решений, влияющих на цели, содержание и сроки проекта или контрольных точек;
· наказания за просрочку или ошибки;
· обсуждение проблем и поиск причин просрочки сроков.
Также необходимо настроить необходимую отчетность в ИСУП, определить ответственность за контроль проведения коммуникаций и ответственность Руководителя проекта. Как правило, ответственным за контроль проведения совещаний является Проектный офис – он контролирует согласование договоренностей по целям, времени и продолжительности совещания, а Руководитель проекта отвечает за подготовку повестки и фиксацию протокола.
Значительно ускоряет проведение совещания использование систем web-конференций, когда Руководитель проекта может демонстрировать участникам отчетность, документы, решения и комментировать их. Протокол совещания также можно вести по ходу коммуникации, одновременно показывая формулировки и, тем самым, согласовывая их.
|
Вопрос |
Ответ |
1 |
Как организовывать короткие коммуникации, если команда проекта большая – 30, 50, 100 человек? |
В больших проектах участников разделяют на небольшие группы по 5-7 человек, назначают руководителя группы и организовывают мини-совещания по группам. Руководитель проекта проводит регулярные совещания только с исполнителями, которые подчиняются непосредственно ему или с руководителями групп. |
2 |
Как можно сократить время для согласования протоколов совещаний с Заказчиками? |
Нужно подводить итоги совещания по окончанию, проговаривая принятые решения и устанавливать короткие сроки для согласования – пока принятые решения еще актуальны. |
3 |
Могут ли в проекте быть только мини- совещания? |
Нет, в проекте должны быть различные форматы совещаний, в том числе обсуждение проблем и поиск решений. С Заказчиком совещания должны быть более продолжительными, чтобы Заказчик мог задать свои вопросы, обсудить интересующие его темы. Но с точки зрения регулярных совещаний с командой – как плановые могут быть только короткие. |
4 |
Как выдержать короткое совещание в 15 минут, если в проекте обнаружена проблема, и все участники готовы ее обсудить? |
Если все участники мини-совещания являются участниками совещания по решению проблемы, для решения проблемы достаточно информации, и у всех участников есть время для обсуждения, можно завершить повестку мини-совещания и начать совещание по решению проблемы. |
5 |
Можно ли отменить мини-совещание, если в проекте аврал? |
Как правило, в период аврала потребность в коммуникациях – определения требуемых к выполнению задач, обмена статусами, единого понимания проблем значительно выше, чем в период стабильной работы. В таких случаях мини-совещания проводят ежедневно или дважды в день, чтобы лучше скоординировать работу группы. |
4.5. Принятие решений на высоком уровне и оценка деятельности
4.5.1. Должно ли Руководство включаться в управление проектами?
Проектные компании получают основную долю дохода за счет выполнения проектов, поэтому Руководство таких компаний крайне заинтересовано в контроле проектов и непосредственно участвует в принятии решений по ним. При достижении определенной зрелости процессов возникает отдельный коллегиальный орган для рассмотрения вопросов проектов, принятия решений и внесения изменений.
Если говорить о выполнении проектов в непроектных компаниях, то Руководство не всегда хочет и может из-за недостатка времени включаться в управление такими проектами. Это связано с несколькими причинами:
· основной доход компании не связан с выполнением этих проектов;
· продукты таких проектов требуют специализированных компетенции для их оценки;
· большинство проектов поставляют результаты для совершенствования операционного цикла и достигают своих целей спустя продолжительное время после завершения проекта;
· проекты слишком различны по структуре работ и получаемым результатам, поэтому управление требует больших усилий.
И в том, и в другом случае участие Руководства в управлении проектами необходимо. В случае непроектных компаний участие Руководства требуется даже больше, ведь у проекта в этом случае редко есть аналог, сотрудники менее готовы к выполнению проекта, а Руководитель проекта наделен меньшими полномочиями в принятии решений.
Как и всякую другую деятельность, на которую выделяются ресурсы, управление проектами нужно обеспечить регулярными процессами управления со стороны Руководства. Именно процессы регулярного менеджмента обеспечивают стабильность получения результатов проекта, даже если они являются уникальными.
4.5.2. Проектный комитет как важнейший элемент регулярного менеджмента
Одним из ключевых процессов регулярного менеджмента является совещание по рассмотрению статуса проектов. В разных компаниях оно называется по-разному, общепринятое название – Проектный комитет.
Основными задачами комитета, как правило, являются:
· утверждение стандартов, методик и правил управления проектами и изменений к ним;
· утверждение целей проектов в соответствии со стратегией организации;
· утверждение результатов проектов (Контрольных точек высокого уровня), достаточных для достижения проектных целей;
· разрешение конфликтов на уровне РП, Куратора и Заказчика по содержанию, срокам и бюджету проектов;
· утверждение требуемых изменений результатов проектов;
· разрешение конфликтов по использованию трудовых и материальных ресурсов в соответствии с приоритетами проектных целей;
· остановка или отмена проектов в связи с изменением стратегического видения.
Как правило, регулярными вопросами на Проектном комитете являются рассмотрение статусов проектов и принятие решений по запросам от Руководителей проектов. Вопросы, связанные со стратегией, рассматриваются исходя из стратегического цикла. А вопросы перераспределения ресурсов могут иметь «пожарный» характер.
Председателем Проектного комитета обычно назначается Генеральный директор или его Первый заместитель, а в состав комитета входят топ-менеджеры, которые участвуют в определении стратегии. Высокий ранг членов комитета проецируется на требования к подготовке заседания, его материалов, выполнение решений комитета. Ни один другой орган или отдельное лицо не должен иметь возможность отменить решение комитета или проигнорировать его – только так можно обеспечить неизменное продвижение проектов.
Основные правила проведения Проектного комитета не слишком отличаются от правил проведения других регулярных совещаний. Важное отличие состоит в том, что Проектный комитет
– это своеобразная демонстрация требований Руководства к качеству управления.
Неумение на высшем уровне выстроить процесс регулярных совещаний по статусам проектов быстро проецируется на все управление проектами, и наоборот – четко поставленный регулярный процесс совещаний Топ- менеджмента по проектам становится фундаментом для подражания и поведения Руководителей проектов на нижнем уровне.
Основные правила проведения комитета:
· Одно из первых правил проведения – регулярность. Именно через регулярные совещания по портфелю проектов, которые проходят в один и тот же определенный день и в одно и то же время, Топ- менеджмент может ясно и четко донести до всех сотрудников важность Проектного управления и свою приверженность ему. Зафиксируйте день недели, время и помещение для регулярного совещания.
· Проектное управление – это умение достигать результат в заданные сроки. Поэтому комитет должен начинаться всегда вовремя, независимо от состава участников. Это должно стать традицией.
· Важно понимать, что Проектный комитет – в первую очередь, отчетное мероприятие, определите единый стандарт отчета, который рассматривается на комитете, и шаблоны для единичных запросов. Все участники должны быстро ориентироваться в представленной информации.
· Не следует совмещать вопросы комитета с мозговыми штурмами, контролем поручений, планированием работы подразделений и другими видами деятельности, не относящимися к контролю проектов. Определите темы вопросов, которые рассматривает комитет.
· Определите стандарт подачи вопросов для рассмотрения. Назначьте секретаря комитета, сделайте его ответственным за контроль соблюдения принятых стандартов, приглашение участников, оповещение об изменениях и т.п.
· Важно фиксировать повестку комитета. Для отражения статуса проектов может использоваться онлайн отчет из ИСУП, который заранее обозначит членам комитета текущие проблемы и риски, которые зафиксировала система (см. рис. 9).
· Все решения комитета должны быть не просто зафиксированы в протоколе, а найти свое отражение в работах проектов. Проектный офис должен контролировать проникновение решений комитета на тактический уровень управления.
Помимо общих правил управления совещаниями, есть рекомендации, характерные именно для проведения Проектного комитета. Рассмотрим их:
· Главная задача Руководства – грамотное принятие решений, а не поиск нужной информации. Не усложняйте требования к материалам. Определите простой набор индикаторов для вопросов, например, «зеленый»-«желтый»-«красный», который сразу обозначит зоны для информирования, внимания и углубленного рассмотрения.
· Начинайте с «зеленых» проектов и отпускайте
Руководителей проектов после доклада. Так вы сэкономите их время.
· Проблемные проекты рассматривайте в конце. Не пытайтесь на совещании решить проблему если она серьезна, лучше назначьте отдельное совещание. Задача комитета – зафиксировать факт проблемы, оценить ее серьезность и определить, кто нужен для ее решения.
· Характер деятельности Топ-менеджмента и Руководителей проектов может мешать стабильному присутствию на совещании. Правила организации должны максимально обеспечивать кворум. По возможности, используйте системы web-конференций для дистанционно удаленных участников.
· Используйте «живой» отчет – онлайн просмотр отчета на экране телевизора или проектора с возможностью углубиться в детали проекта, если это необходимо.
· Собирайте оценки по качеству совещания от его участников, особенно первое время. Так вы сделаете его максимально полезным на основе полученной обратной связи.
|
Вопрос |
Ответ |
1 |
Как взаимодействуют Проектный офис и Проектный комитет? |
Проектный офис подчиняется Проектному комитету и является его «правой рукой». Даже если у комитета есть собственный секретарь, Проектный офис отвечает за корректность подготовки материалов заседания, своевременную рассылку требуемой отчетности, а также построение онлайн отчетов в ИСУП для демонстрации их непосредственно на комитете. |
2 |
Кто должен быть на ПК: Топ-менеджмент или Заказчики проектов? А если они не совпадают – у нас много заказчиков, их всех звать на этот комитет? Или если у нас Топ-менеджмент (Генеральный директор) не всегда является Заказчиком проектов, нужно ли его приглашать на ПК? |
Обязательными участниками комитета для рассмотрения статуса проектов являются утвержденные члены комитета и Руководители проектов. Если на комитете рассматривается отдельный запрос, требующий высокоуровневого решения, тогда на комитет приглашается Заказчик проекта. Генеральный директор участвует в комитете, если он является Председателем или Заказчиком проекта, по которому сформирован запрос для принятия решения. |
3 |
Как часто нужно проводить ПК? |
Частота проведения Проектного комитета должна соответствовать потребности в скорости решения тех вопросов, которые на нем рассматриваются. Если рассматриваются еженедельные вопросы управления, а комитет проходит редко – это будет тормозить управление. Если комитет проходит часто, а вопросы для его рассмотрения накапливаются медленно – это снизит мотивацию Руководства. Регулярно отслеживайте статус проектов, эти вопросы можно рассматривать ежемесячно, ежеквартально или раз в две недели, в зависимости от темпов ваших проектов. |
4 |
Сколько времени должен длиться комитет? |
Стандартное время для проведения комитета – от получаса до полутора часов. Не стоит делать более длительные заседания. Следуйте следующим правилам: · Останавливайте обсуждения, которые не служат целям комитета. · Определите формат для рассмотрения вопросов. · Определите регламентное время рассмотрения «зеленых», «желтых» и «красный» проектов. · Если вы не укладываетесь в определенное время, то должно назначаться дополнительное заседание. |
5 |
Что делать, если проект требует решения Руководства, а комитет будет только через две недели? Останавливать работы? |
1. Определите уровень рисков, которые требуют внепланового заседания: запрос клиента или внешнего Заказчика, требования государственного регулятора, выгода или угроза с лимитом (например, от решения зависит выгода в 1 млн руб.). Тогда секретарь сможет организовать совещание для экстренного решения. 2. Сформируйте перечень вопросов, которые можно решать заочно. Тогда вы сможете экономить время очного совещания и ускорить ответ Руководителям проектов по текущим и наиболее частым вопросам. |
Проектный комитет – коллегиальный орган, принимающий управленческие решения в части планирования и контроля проекта, достижения контрольных событий и показателей проекта в соответствии с действующими программами и портфелями проектов, а также операционной работой организации.
4.6. Закрытие проекта и анализ результатов
4.6.1. Как правильно выполнить закрытие проекта
Во внешних контрактах для подтверждения передачи результата или поставки используются акты приема-передачи. Для управления проектами на уровне организации также должна быть разработана форма итогового отчета с фиксацией полученных результатов. Итоговый отчет может фиксировать:
· что и в каком количестве является результатами проекта;
· решения по урегулированию вопросов (как должно использоваться, какие ограничения эксплуатации и т.п.);
· решение о вводе в промышленную эксплуатацию;
· приемочная комиссия;
· итоговые параметры проекта и их отклонения от уставных значений (продолжительность, бюджет, использованные ресурсы);
· оценка удовлетворенности Заказчика: качеством, результатом, управлением проекта;
· оценка качества управления проектом от Проектного офиса.
Важно зафиксировать дату Закрытия проекта и снять ответственность за эксплуатацию продуктов проекта с Руководителя проекта. Одновременно важно передать Заказчику проекта ответственность за использование продуктов проекта и достижение целей. Итоговый отчет является эстафетной палочкой, которая продвигает организацию к достижению поставленных целей, и она должна быть формально передана.
На основании данных отчета может быть рассчитана проектная премия. Также данные по отклонениям проекта должны попадать в отчетность Проектного офиса и являться одним из показателей его деятельности.
Например, один из показателей эффективности Проектного офиса может быть сформулирован так: «проекты по развитию производственных линий должны выполняться с отклонением срока завершения не более 7%».
4.6.2. Какие последние действия Руководителя проекта?
Помимо подготовки итогового отчета в ответственность Руководителя проекта входит анализ выполнения проекта и извлечение уроков. Должны быть зафиксированы ошибки, допущенные в проекте, и способы их избегания в будущих проектах. Напротив, если в проекте был найдено удачное решение – стоит зафиксировать эту находку и способ ее повторения.
Часто эту функцию передают Проектному офису. По завершении проекта Проектный офис организовывает совещание с командой проекта и фиксирует положительный и отрицательный опыт, полученный на проекте. Зафиксированные стратегии реагирования должны не просто храниться в архиве, они должны найти отражения в активах управления – документах, процессах, настройке информационной системы, шаблонах. Анализ проекта направлен на то, чтобы следующие подобные проекты выполнялись успешнее.
|
Вопрос |
Ответ |
1 |
Как фиксировать отклонение срока проекта, если в ходе проекта срок был перенесен по объективным причинам, не зависящим от Руководителя проекта? |
В этом случае все равно нужно зафиксировать отклонение проекта как факт. Применение мотивации для команды проекта или учет показателя эффективности Проектного офиса возможно с оговоркой на обстоятельства переноса срока, которые должны быть также зафиксированы в итоговом отчете. |
2 |
В каком формате делается итоговый отчет – текст, таблица или презентация? |
Для Заказчика лучше делать презентацию результатов, особенно если Заказчик – лицо высокого ранга. Но остальные итоговые данные должны быть зафиксированы в текстовом или табличном варианте по единому шаблону. |
3 |
Что делать, если Заказчик отказывается принимать результаты? |
Руководитель проекта должен либо зафиксировать формальный запрос на изменение, либо, если имеются факты расхождения итогового результата с требованиями Устава, выполнить доработку. В остальных случаях требуется проводить переговоры с привлечением Кураторов проекта. |
4 |
Нужно ли делать анализ результатов, если проект типовой? |
Для типовых проектов анализ результатов наиболее важен, так как они выполняются чаще других. Но форма анализа может быть упрощена – например, сформирована стандартная анкета с возможными вопросами. |
5 |
Имеет ли смысл анализировать исполнение проекта, если проект уникальный и никогда более не будет повторен? |
Анализ проекта должен выполняться в любом случае. Знания об уникальном проекте или его продукте должны быть зафиксированы, чтобы можно было и повторить проект, и использовать эти знания в других проектах. |
Вместо послесловия
Итак, вы приняли решение о внедрении проектного управления в своей компании. И прочитав книгу, уже знаете, с чего начать и что для этого нужно сделать. Для постановки системного управления проектами и достижения результата вам потребуется надежный и удобный в использовании программный продукт.
С его помощью вы всегда будете иметь под рукой актуальную картину по проектам: статусы, план/факт, проблемы в режиме реального времени, сможете вести коммуникации, проектный документооборот, фиксацию и контроль поручений, промежуточных результатов и, что немаловажно, снизить затраты на ручной труд.
Источник http://www.advanta-group.ru/