На определенном этапе развития бизнеса многие компании сталкиваются с внутренними ограничениями, которые выражаются в сложности выполнения проектов развития – будь то организационные изменения, внедрение новых продуктов, улучшения бизнес-процессов или же внедрение новых цифровых инструментов. Неожиданно выясняется, что и вся система управления в целом и отдельные руководители больше «заточены» под выполнение регулярных функций. А когда появляется разовая нетипичная задача, то качество управления резко падает, и проекты развития не выполняются.
В этой ситуации руководство приходит к пониманию важности настройки проектного управления в компании. Но часто под «внедрением проектного менеджмента» подразумевают освоение проектного софта – Jira, MS-Project... Конечно, эти программы полезны и удобны, но для эффективной проектной работы одних технических средств недостаточно. Здесь успех опирается на «культуру проектного управления», которая связана не столько с софтом, сколько с управленческой гибкостью руководителей, их умением работать с проектной командой.
Основные сложности проектного менеджмента
Речь не о тех областях деятельности, которые изначально организованы по проектному принципу, например, «капитальное строительство» или «разработка ПО». Эти области – проектные по своей природе, там работа строится по четкой методике, без необходимости рефлексии «в каком подходе мы сейчас работаем».
Но есть области, где проектные задачи часто перемежаются с типичными. Например, в работе HR-директора регулярные процессы подбора переплетаются с разовыми проектами, такими как «внедрение системы грейдов» или «формирование кадрового резерва». В этом главная сложность – когда проектные задачи «маскируются» под регулярные. И не всегда понятно, как работать с новой задачей – как с регулярным процессом, или как с разовым проектом?
Стереотипы регулярного менеджмента
В этих условиях культура проектного управления проявляется в готовности руководителя оценить тип задачи и по необходимости отойти от стереотипов регулярного управления, организовав работу на принципах проектного управления. Какие же стереотипы чаще всего мешают руководителям успешно управлять проектами, и как следует организовать работу над проектными задачами?
Стереотип 1: «Проект нужно выполнять своими силами»
Каждый руководитель управляет определенным ресурсом, и отвечает за его эффективное использование. Но проектные задачи, как правило, требуют компетенций из разных областей, поэтому проектная команда – это не всегда сотрудники одного отдела. Пытаться выполнить проект силами только своих непосредственных подчиненных – это ошибка. Лидер проекта должен уметь сформировать кросс-блоковую команду из сотрудников разных отделов.
Стереотип 2: «Сотрудники по умолчанию мотивированы на работу в проекте»
Руководитель по привычке рассчитывает на вовлеченность сотрудников просто по факту их работы в компании. И может быть неприятно удивлен, увидев низкую заинтересованность команды к проектной работе. Следует помнить, что нетипичные задачи чаще всего лежат за рамками должностных инструкций персонала, а значит, участникам нужна дополнительная мотивация для работы в новом проекте – как материальная, так и нематериальная. Таким образом, умение сформировать и мотивировать проектную команду – фундамент культуры проектного управления.
Стереотип 3: «Правильный процесс ведет к правильному результату»
В регулярной деятельности внимание больше сфокусировано на качестве операций, в целом, на «процессе». В проекте же приоритетен не процесс, а «образ конечного результата», а также этапы его достижения. Руководитель должен уметь формировать конечный образ результата и показывать ключевые вехи, которые лежат на пути к этому результату (либо хотя бы ближайшие шаги, если высока доля неопределенности и работа идет по Agile).
Стереотип 4: «Хороший план гарантирует успех»
Жизненный опыт руководителя говорит о важности хорошего планирования – чем тщательнее составлен план, тем выше гарантия получения требуемого результата. Эта установка дает «иллюзию контроля» в проектной работе, и снижает требования к мониторингу в процессе. «Зачем мне погружаться в проект на середине пути, если пока нет результата? Вот когда настанет час X, тогда и буду принимать итоги. А сейчас что может пойти не так, если все тщательно спланировано?» – может рассуждать руководитель.
Но проект, в отличие от регулярной деятельности, всегда сопряжен с новизной и повышенными рисками. И выполнение базовых критериев успешности проекта (качество, сроки, ресурсы) будет возможно только при постоянном анализе и упреждении рисков в процессе работы. Поэтому регулярный мониторинг работы, внесение корректив в исходный план, предупреждение рисков – неотъемлемые части культуры проектного управления.
Стереотип 5: Проектные задачи можно решать вместе с регулярными
У многих руководителей есть соблазн объединить проектную деятельность с текущей работой – например, рассматривать проектные вопросы наряду с регулярными на общей планерке. Тут важно помнить, что у каждого проекта должен быть свой «операционный ритм», который лучше не смешивать с регулярным ритмом подразделения (планерками, оперативками, встречами).
Так, на старте полезно провести с командой «Сессию по инициации проекта», а далее регулярно проводить по данному проекту «Статус-встречи» с обязательным анализом рисков и оперативным внесением изменений в план работ. В конце полезно провести «Сессию по выученным урокам», чтобы снизить риски для аналогичных проектов в будущем.
Выводы
Понимая отличие регулярной и проектной деятельности и формируя операционный ритм проекта, мы закладываем основу для культуры проектного управления в компании.
Также читайте:
Да, любой проект - это в том числе и политика. Как правило мелкая, часто внутрикорпоративная, но все же политика. И если человек прямо такой менеджер-менеджер, но этого не понимает, у него могут быть проблемы с реализацией проектов.
И любые другие проблемы. Менеджер не может об этом не знать и не учитывать.
Конфликты интересов, включая потенциальные, объективно присутствуют в любой организации, с ними нужно уметь работать.
Ещё раз прочитайте. Думаю, что-то прояснится.