Чтобы еще больше поддержать вас на пути постоянных улучшений, мы предлагаем вам воспользоваться специальным предложением, которое будет действовать весь 2024-й год. Воспользуйтесь сертификатом и получите 10 000 рублей на комплексную информационную систему ПМ Форсайт СТАНДАРТ или стратегическую сессию.
Грамотно и профессионально управлять проектной деятельностью в небольших организациях так же важно, как и в крупных компаниях. При этом ключевой вызов для небольших организаций заключается в том, чтобы найти баланс между адаптацией мировых практик и поиском собственного подхода.
29 сентября на площадке Аналитического центра при Правительстве РФ эксперты с многолетним опытом искали ответ на вопрос – как найти баланс? У каждого из них за плечами есть опыт построения СУПД для небольших организаций и проектных команд в коммерческом и государственном секторе. Они высказывали мнение по теме, приводили примеры из личного профессионального опыта.
На заданную тему общались:
На входе эксперты договорились, что под небольшой организацией они будут называть коммерческие организации численностью до 500 человек с количеством небольших проектов до 30 или крупных проектов до 5 в год, а также государственные бюджетные учреждения, администрации муниципальных образований и др.
«У консультантов есть поговорка: «О терминах не спорят, о терминах договариваются». И мы здесь договоримся, что в рамках сегодняшней дискуссии мы, скорее всего, такого рода, такого масштаба организации будем называть небольшими.
Мы прекрасно понимаем, что проект проекту рознь, что одна организация определяет небольшой проект, как проект длительностью в 3 месяца и 50 миллионов рублей. Для какой-то организации это нормальный проект, и она будет называть его крупным».
По итогам встречи были сформулированы наиболее важные аспекты управления проектной деятельностью в небольших организациях.
- Даже в небольшой организации применим и полезен системный подход, опора на небольшой, ограниченный, но типовой набор востребованных функций, должны быть зафиксированы договоренности о терминах и о процессах.
- В команде должны быть внутренние и внешние амбассадоры-посланники, на которых можно опираться при внедрении проектных подходов.
- Хорошо, когда присутствует консультант, к его мнению нужно прислушиваться. Мнение это нужно делить пополам, т.к. он не знает глубоко культуру компании. Тем не менее, у него есть опыт внедрения проектной деятельности и есть право говорить правду в лицо ТОП-руководителям. Это та непростая задача, которую должны решать умелые и правильные консультанты.
- Важно, чтобы за плечами подрядчика, который привносит проектное управление в небольшую организацию, был релевантный опыт не только в разработке ИТ, но и в методологических решениях. И здорово, если этот опыт есть в разных секторах: в коммерческом, в государственном секторе, в больших и малых организациях. Это позволяет учитывать специфику и предлагать правильные решения.
- Не стесняться внедрять «коробку» в качестве ИТ-решения для автоматизации проектной деятельности и использовать базовый набор функций.
- Хорошо, когда в информационную систему зашиты какие-то базовые стандарты и регламенты, без этого никуда.
- Надо не забывать про клиентоцентричность. Система управления проектами и информационная система не должны перегружать ту команду, которая делает проекты. Не должно быть так, чтобы система нагружала команду какими-то дополнительными обязанностями, но не привносила бизнес-ценности, бизнес-полезности.
Эксперты также поделились конкретными советами как найти баланс в построении системы управления проектной деятельностью и примерами их успешного применения.
Определить ТОП-10 самых востребованных проектных задач.
«Глобально мы должны понимать деньги, ресурсы, количество проектов.
Первый вопрос от генерального директора: «Как руководить, что у нас вообще происходит?». Поэтому первая, на мой взгляд, задача – это единое пространство для хранения проектных активностей.
Второе, что требуется глобально от информационной системы управления проектами – рано ли поздно возникает вопрос ресурсов.
Что сюда вкладывается? То, насколько проекты обеспечены ресурсами, надо ли еще принимать людей в штат, насколько наши проекты с точки зрения денег покрывают затраты на персонал, участвующий в проекте. Вот две вещи, которые, в принципе, требуются.
Что бы главного я еще выделил? Наверное, это дашборды, то есть сбор информации для принятия управленческих решений. Он может быть разный в зависимости от направленности организации. Но, в общем случае – это некий отчет по статусу. Также должен быть отчет по статусу портфеля.
Если мы смотрим не глазами руководители компании, а со стороны линейного руководителя, руководителя проекта, то первая задача – это статус и отчет по проекту. Что у меня в проектах происходит? Куда мне нужно двигаться? Т.е. это управление по отклонениям, понимание того, почему мы вышли за рамки проекта и что с этим делать».
«Первая вещь – это стандарты, то есть если ты правильно внедряешь систему управления проектами, там есть система и методология. Через них ты учишь людей работать с единым информационным полем и единым пониманием инструментов, с которыми ты работаешь, а также с едиными критериями оценки. В гибких системах это называется «definition of done» или «definition of accept». То есть критерии готовности продукта, когда у всех появляется единое информационное поле по этим критериям.
Здесь важны единое информационное поле, единое понимание инструментов и конечного результата. И проектное управление в данном случае отвечает на оба этих вопроса: «Как ты будешь это делать?» и «Что будет являться конечным результатом твоей работы?» Если ты по этому поводу договоришься, то дальше уже дело техники, какие из компонентов проектной деятельности ты будешь использовать в данном конкретном аспекте. Хоть все 25, которые перечислены на слайде выше, хоть один, хоть два, хоть три, хоть четыре.
Тот же kanban — это суперкрутой инструмент, но надо понимать, что мы имеем в виду и не усложнять.
И важный акцент… Надо научиться еще читать три четверти ГОСТ в старой или новой редакции, потому что это дает достаточно хорошее понимание того, как работать с требованиями».
«Подведу итого сказанного. Для небольших организаций скорее важны бюджет, сроки, ресурсы, какой-то текущий статус понимания сигналов того, где мы сейчас находимся. И, наверное, для руководителей организации, которые являются руководителями портфелей, важен статус портфеля.
Также нужно работать со всеми участниками проектной деятельности, и не только теми, кто делают продукты, но и с владельцами процессов, функциональными руководителями, которые часто просто не понимают, о чем с ними говорят».
Выбрать подходящее под задачи ИТ-решение и привлечь стороннего консультанта.
«Я бы сразу сказал, что тут однозначно пойдет итерационный подход. И он в большей степени связан с психологией людей, а не с эффективностью, потому что сколько человеку не объясняй, он все равно пойдет через опыт пользователя.
Поэтому однозначно первая итерация — это типовое решение, базовое, с быстрым внедрением.
Запустили, поработали с людьми, если есть достаточный уровень организации команды, собрали обратную связь, собрали юзер-стори, и на основании этого уже можно делать какую-то историю, связанную с ТЗ.
Потом ты делаешь анализ различных систем с точки зрения плюсов и минусов, когда у тебя критерии, отклонения, и баллы насчитываются чисто автоматически по тем или иным критериям, и выбор происходит на основе данных, то есть тебе цифры говорят о том, что это самый эффективный инструмент. И потом ты уже начинаешь, во-первых, понимать, нужно тебе это или нет, во-вторых, понимать, что любой ИСУП несовершенен, он тебя все равно устраивать не будет, какой бы то он ни был. Тебе придется его либо кастомизировать, либо писать заново. Ты начнешь это делать, убьешь кучу денег, разругаешься со всеми айтишниками-разработчиками, которые тебе скажут, что то, что вы хотите, этого даже у Сбера нет, а за ваши 150 тысяч рублей идите вон карандашиками на стене пишите. И ты поймешь, что тебе все равно придется вернуться к какой-то истории универсальной коробочной разработки от известных фирм, которые осуществляют постоянную поддержку и изменение этих программ.
В моей картине мира ты должен не пожалеть время и деньги, и при выборе ИСУП однозначно нанимать консультанта, именно эксперта в области управления проектами. Потому что какие бы ни были крутые вендоры и владельцы ИТ-продуктов, они все-таки владельцы ИТ-продуктов. Да, они айтишники, но вот то, какие инструменты, по каким методикам должны работать с точки зрения проектного управления, они тебе не скажут».
«Я целиком и полностью поддерживаю подход, который описал Егор. Более того, другого осмысленного пути не существует. Это четвертая компания, где я это делаю. И такой подход точно работает.
Если я хочу выкинуть какую-то ценность из ИСУП, потому что она неинтересна, то ИТ-вендор выкинет ее без проблем, а эксперт в области проектного управления скажет: «Уважаемый, ты, конечно, можешь это выкинуть, но есть жизненный цикл проекта и в нем это важно».
Поэтому на мой взгляд, при внедрении ИСУП важно, чтобы у тебя был экспертный взгляд со стороны в лице специалиста, который тебе подскажет, направит и вместе с тобой этот путь пройдет.
Когда ты ставишь коробку, с уже «зашитым» туда функционалом — это очень хорошая помощь для внедрения проектного управления. Там есть все базовые процессы. Они так или иначе описаны. Их придется выполнять, как бы вы ни хотели. И это вопрос административного рычага, который у вас есть. Готовы вы этот административный рычаг включить и заставить людей выполнять определенные действия? Опять же, не до крайностей, но такой подход точно работает.
Для управления проектами нужны разные инструменты. Но если мы говорим про само управление конкретным проектом или конкретным портфелем, то здесь я бы рассматривал именно платформенные решения, потому что они позволяют достаточно быстро поиграться с прототипами того, ЧТО вам нужно, понять НУЖНО ВООБЩЕ или нет и, уже не переходя на другую платформу, не выкидывая коробку, не выбирая какую-то другую, двигаться дальше.
Надо понимать, что с увеличением количества людей первый вопрос, который встанет – это кто дает права, как это должны быть права, и что делать в случае появления ошибок, т.е. кто их исправляет. Этим должен заниматься либо уже готовый проектный офис, если он есть, либо продвинутый технический сервис, либо вендор. И тут мы опять приходим к коробке».
«Меня радует, что сначала у нас мнения объединились, и мы прошли путь от коробки к платформе и обратно вернулись к коробке.
Также мне откликается мысль, что нужен профессионал, который разбирается в проектном управлении, но при этом, как у нас водится, в своем отечестве пророка нет, нужно и свои мозги включать. Консультанта нанимаем, делим его советы напополам, но консультант все-таки нужен.
Если за ИТ-продуктом, в частности, за информационной системой стоит компания, которая понимает, как выстраивается методология, методики проектного управления в разных организациях, в разных условиях, в разных масштабах, то решение будет больше соответствовать вашим условиям, и вам должны предложить не универсальный подходящий всем продукт, one-size-fits-all, а с учетом специфики вашей деятельности.
С чего начать?
«Я бы начал с терминов, потому что мы должны говорить на одном языке.
Вторая часть – это правила. Неважно, как это назвать: инструкция, регламент, положение. Они должны быть достаточно верхнеуровневыми, не должны мешать работать конкретным людям внутри проекта, но, тем не менее, содержать в себе правила работы, отбора проектов, контроля, мониторинга….
И только после этого или параллельно с этим думать, каким инструментом все это можно автоматизировать».
«Как любой элемент управления, проектное управление — это элемент управления организации. Мы из 10-летней практики выработали универсальный подход, как внедрять новые системы. Он состоит из трех блоков.
Первое — это работа с культурой, с обучением, с созданием интерфункционных полей, договоренностей на берегу, ценностей.
Второе — это выстраивание операционного управления текущей деятельностью по этой системе.
Третье — это деятельность, связанная с реинжинирингом, сейчас модно реинжинирингом называть деятельность, связанную с улучшениями и апгрейдами этих систем.
Когда по этим трем блокам есть определенные планы, нужно договориться с лицами, принимающими решение, по дорожной карте. Также в любом случае нужно договориться о быстрых победах, взять какие-то простые задачи, которые можно решить с помощью внедрения этой новой системы для того, чтобы поработать именно с мотивацией, с убеждением, потому что внедрение любых новых инструментов и методик – это прежде всего борьба с системой.
Система ненавидит изменения. И лучше, чем быстрыми победами и договоренностями на берегу, не справиться.
Если ты внедряешь новые системы в «красных» структурах, которых больше 80% в России, то однозначно должны быть люди, которым доверяют первые лица. И лучше, чтобы это были внешние консультанты. Да, должна быть команда драйверов внутри, это вообще не обсуждается. «Токсик» должен быть извне, потому что это единственный человек, который может сказать руководителю о том, что он не прав, а это при внедрении изменений чуть ли не ключевая вещь. Иначе просто система будет работать неэффективно».
«Подведу краткий итог сказанного. Для того, чтобы начать управлять проектной деятельностью небольшой организации нужны: системный подход, обучение, договоренности, ценности, также договоренности о терминах и правилах и еще типовое решение.
Важный момент, в самом начале важно договориться, а какую проблему мы решаем, и чья она, чтобы одинаково понимать, о чем идет речь.
Прозвучал тезис, что важен консультант. Еще один довод в пользу консультанта в том, что он может прийти в организацию и говорить правду в лицо.
И еще важно наличие внутренних амбассадоров, но без участия первых лиц, без заинтересованности руководителей и каких-то пилотных проектных команд ничего не взлетает. Я думаю, что здесь неважно, вы большая или небольшая организация. В небольшой организации, эти проблемы, наверное, даже больше обостряются».
Госсектор или коммерческая компания. Есть ли разница внедрения проектных подходов?
«Прежде всего, это разница во внутренних системах управления. В госсекторе эти системы управления направлены на то, что горизонтально договариваться бывает невозможно. То есть тебе нужно для того, чтобы решить какой-то вопрос, подняться доверху по цепочке.
С коммерческими организациями все немножко проще. Там есть горизонтальные связи. Это разная система управления. Разная реакция на инциденты в государственном и в коммерческом секторе. Но в государственном управлении это гораздо ярче проявляется.
Я бы сказал, что административный рычаг в государственном управлении выше. Если я уже до чего-то договорился, если я создал регламент, то уже есть рычаг. Вне зависимости ни от чего. Если мы говорим про коммерческие компании, то здесь административного рычага можно не получить никогда».
«В государственном секторе более жесткая структура, инерционность и, может быть, меньше гибкость. Но в этой системе есть свои плюсы. Иерархичность, подчиненность и обязательность исполнения тех вещей, о которых, может быть, неудачно, т.е. директивно, но все же договорились на берегу».
«Я бы не выделял ГОСы. Если раньше административные рычаги, инструменты в ГОСе работали гораздо более эффективно, чем в бизнесе, то, на мой взгляд, сейчас идет вектор в обратную сторону, потому что приходит молодежь, а у более старшего поколения появляются совершенно другие инструменты, административный регламент уже как таковой определенного значения не имеет.
В бюрократических системах люди очень хорошо учатся обходить административные регламенты и барьеры.
В то же время в бизнесе тоже хорошо работают административные барьеры и регламенты. Тут надо подходить не с точки зрения это ГОС или бизнес, а с точки зрения именно ценностей конкретной организации и людей, которые являются там либо лицами, принимающими решения, либо лицами, не принимающими решения».
Выводы
«Мне кажется, ключевые аспекты мы сегодня подсветили.
Первое. Не стесняться внедрять коробку, брать базовый набор функций. Важно, чтобы за плечами у организации, которая привносит проектное управление, информационную систему управления проектами в небольшую организацию был релевантный опыт не только в разработке ИТ, но и в методологических решениях. И здорово, если этот опыт есть в разных секторах: в коммерческом секторе, в государственном, в больших и малых организациях. Это позволяет учитывать специфику и предлагать правильные решения.
Хорошо, когда у нас присутствует консультант, к его мнению нужно прислушиваться. Наверное, где-то делить напополам, потому что он не знает нашу культуру, он не жил вместе с нами, он не «ходил в наших тапочках» последние пять лет. Но, тем не менее, у него есть опыт внедрения проектной деятельности. И еще у этих парней, которые придут как консультанты, есть право говорить правду в лицо нашим ТОП-руководителям. Это такая непростая задача, которую умелые и правильные консультанты должны решать.
Системный подход – это опора на небольшой, ограниченный, но типовой набор востребованных функций, договоренности о терминах, договоренности о процессах.
Здорово, когда в информационную систему зашиты какие-то базовые стандарты и регламенты, без этого никуда.
И важно не забывать про клиентоцентричность. Система управления проектами и информационная система не должны перегружать команду, которая делает проекты. Мы не должны генерировали новый фетиш или карго-культ: когда система нагружает команду какими-то дополнительными обязанностями, но не привносит в организацию бизнес-ценности, бизнес-полезности и становится какой-то рутиной обязаловкой, а не помощником в реализации проектов.
И последний пункт – наличие внутренних и внешних амбассадоров-посланников, на которых можно опираться при внедрении проектных подходов».
Решение, адаптированное под потребности компаний, которые только начинают внедрение проектного управления. Подходит для компаний малого и среднего бизнеса, органов исполнительной власти, администраций муниципальных образований. Позволяет быстро освоиться в системе и начать управлять проектами на профессиональном уровне. Возможный вариант размещения в облаке гарантирует доступ к данным в любое время из любой точки мира.
Подробнее https://promo.pmpractice.ru/