Один раз меня захейтили…

за мою нелюбовь к процессному подходу в управлении проектами и твердую убежденность в том, что его невозможно применять на практике. 

Однако вчера на моем вебинаре собралось много коллег, которые в очередной раз подтвердили мою мысль – опытные руководители проектов НЕ БУДУТ соблюдать методологию, описанную в виде шагов. Потому что знают, что для достижения нужных результатов, соблюдения сроков и минимизации рисков в реальности вся эта красивая теория по большому счету бесполезна.

Да, описание процессов управления помогает новичкам как базовое обучение, чтобы иметь идеальное представление об управлении проектами. И для многих описание последовательных шагов более привычно и удобно для понимания. Но в итоге на практике работает только система из проверяемых результатов, а не шагов. 

Вчерашний вебинар получился очень емким и содержательным: я не только разобрал «дыры» в нескольких известных стандартах с процессным подходом, но и показал полезное упражнение для создания каркаса собственной технологии с помощью моего авторского метода Парацельс ПМ. А именно: как определять важные области внимания (аспекты) с помощью критериев успеха и неуспеха проекта, а также причин возникающих проблем. 

Конечно, в каждом стандарте или фреймворке есть рекомендованный набор аспектов (в PMBoK, к примеру, это области знаний). Но для создания работающей, небюрократичной технологии управления проектами, которую не захейтят ваши руководители, вам нужно выбрать только те области, которые реально важны для успеха проектов именно в вашей организации. 

Если вы не успели вчера присоединиться, обязательно посмотрите запись – чтобы ее получить, переходите в наш чат-бот.

Встречаемся сегодня в 19:00 – буду менять ваше мышление в управлении проектами. Ссылка на трансляцию будет доступна только тем, кто зарегистируется здесь.

Как управлять неуправляемым?🌪️

Все, что нужно управленцу, чтобы минимизировать риски потери денег и эффектов от проекта – это понятная отчетность с достоверными данными о его прогрессе. Если все идет по плану – отлично, а если что-то пошло не так и сроки растягиваются – быстро разбираемся в причинах проблемы, принимаем нужные решения и едем дальше.

Но что делать, если вам нужно реализовать критически важный и масштабный проект длительностью несколько лет и стоимостью миллиарды рублей в ограниченные сроки, но оценить прогресс его выполнения не получается из-за постоянно меняющегося содержания? 

В этой статье делюсь кейсом создания методологии отслеживания прогресса в масштабной ИТ-программе по разработке и внедрению ПО в крупнейшей телекоммуникационной компании. Данное решение было единственно возможным, чтобы решить проблему заказчика, и я подробно рассказываю о нем и как мы к нему пришли.

🔥Там же привожу пример расчет прогресса – как применение нашей методологии выглядит на практике. Обязательно к прочтению всем, кто сталкивается с реализацией подобных масштабных проектов по разработке.

#кейсы #методология

💥 Переворот в управлении проектами. Парацельс ПМ: результат вместо процесса

22 апреля в 19:00 приглашаю вас на вебинар, где я расскажу о подходе, ориентированном на результат, и почему он является единственной надежной страховкой от рисков.

Что будет на вебинаре:

✅ Почему процессный подход, лежащий в основе большинства фреймворков управления проектами, не работает так, как надо.

✅ Топ рисков, которые возникают, если делать проекты по учебнику, и почему именно они возникают. Как успех проекта зависит от наличия проверяемых результатов в любой точке жизненного цикла.

✅ Процессный подход vs подход, ориентированный на результат. Сравнение подходов, их плюсов и минусов, на примере реализации конкретного проекта.

✅ Что такое результатоориентированный подход и из чего он состоит? Почему этот подход – лучший выбор, если нужны предсказуемые результаты в условиях высокой неопределенности.

✅ Парацельс ПМ – метод управления проектами с подходом, ориентированным на результат. Также поговорим о критериях применимости метода.

✅ Архитектура метода: принципы и ценности, уровни управления, аспекты, артефакты и события, роли. Как создать единую систему, которая будет развиваться вместе с организацией и зачем это нужно.

✅ Как применять Парацельс ПМ? Готовое решение Парацельс ПМ или адаптация его концепции к действующему проектному управлению в организации.

🔥 Также покажу упражнение, как выявлять важные области внимания (аспекты) на базе проблем, критериев успеха проектов и ограничений, чтобы создать кастомный метод управления проектами, закрывающий потребности организации.

Успейте зарегистрироваться здесь, ссылка на трансляцию будет отправлена участникам на емейлы.

Мы с коллегами сделали подборку авторских каналов о проектном управлении и не только. Очень рекомендую добавить себе, чтобы не потерять – там вы найдете множество крутых кейсов, инструментов управления и полезных инсайтов для рефлексии.

Подписаться на всех сразу или выбрать наиболее интересные для себя каналы можно здесь.

Какие каналы есть в папке:

@manoclock - операционный и проектный ИТ топ-менеджер с рефлексией об учёбе, проектах и управлении временем.

@work_out_work - проектный менеджер в ИТ пишет о том, как нарастить свои компетенции через ежедневные действия. А еще немного - в целом про проектное управление и свой опыт.

@tg_guide_with_me — проектный менеджер делится полезными вещами про телеграм. Пользуется им для работы и старается приобщить к нему всех.

@like_spock — руководитель ИТ-компании HFLabs, пишет о переговорах, отношениях с клиентами и управлении. А еще - про клиентский сервис, персональные данные и мир вокруг.

@tetya_yulia - директор по продукту рассказывает байки о жизни небольшого российского b2b saas. 0% фреймворков и дабл даймондов, 100% историй о том, чему с профессиональной точки зрения может научить нашествие на офис муравьев.

@zvukizmeyuki — канал менеджера ИТ-проектов в творческом отпуске. Пишет обо всем, что волнует, тревожит и бесит. А по субботам — решает управленческие задачки. Присутствует нецензурная лексика.

@akudlay - личный канал руководителя проекта с более чем 20 стажем о теории и практике управления инвестиционно-строительными проектами. Публикует разборы, реальные кейсы, рабочие схемы, приёмы для тех, кто ведёт стройку, проектирует и производит, просто работает с подрядчиками.

@A_B_C_Consulting - канал-предупреждение о том, как не стоит строить консалтинговый бизнес. Без иллюзий, без фальшивой глубины и с полным погружением в абсурд корпоративного мира.

@projectvkarmane - повесть о развитии начинающего руководителя проектов. Сурово, непонятно, с умными словами и умными статьями.

@upravlenieproektami – руководитель проектного офиса пишет о теории и практике проектного управления, а также публикует кейсы для решения и истории из повседневной жизни руководителей проектов

Еще один канал - для вдохновения:

@dwoeprotivvetra - мотопутешествие руководителя проекта и владельца продукта через всю страну. А прикрывает их в этом админ 🏍

И самое милое, что вы видели сегодня:

@moscow_pandas - канал про уникальных московских панд со звездой Катюшей, чтобы позалипать на живущих в свое удовольствие зверюшек 🐼

Коллеги, подписывайтесь, рекомендую🤝

А виноват ли проектный офис?

Я часто слышу от своих коллег, руководителей проектных офисов и программ, одну и ту же историю, когда руководство компании решает «начать жить по-другому». А именно: давайте внедрим единый стандарт управления проектами, и тогда у нас все наладится – поймем, куда уходят деньги, научимся лучше планировать, оптимизируем имеющиеся ресурсы и т.д.

И часто такое новое решение это либо готовый фреймворк, который показал свою эффективность в других организациях, либо же популярный стандарт по управлению проектами.

Но каждый раз эта история, инициатива «сделать все учебнику» или «как у других», заканчивается полным фиаско – все делается «как надо», но сотрудники тонут в бумажках, а эффективность нового стандарта оказывается под большим вопросом. И, самое главное, непонятно, почему так вышло – то ли новые правила не удалось встроить в процессы, то ли их просто игнорируют. А в итоге руководство винит методологов – в Газпроме же это работает, а у нас почему нет? Что вы делаете не так и кто виноват?

И правда, кто виноват на самом деле?

В прошлом году на своей диагностической сессии я услышал от одного опытного руководителя проектного офиса то, что по моему мнению является корнем зла. А именно: «У нас так принято, что высшее руководство не делится стратегическими целями компании. Поэтому как проектный офис может помочь бизнесу, остается только гадать». 

💡 Создание работающей, полезной методологии начинается не с готовых фреймворков или чужих «лучших» практик, а с понимания, какие потребности организации она должна закрывать. 

Будем честны – проектный офис не должен играть в угадайку, пытаясь определить, как именно новый стандарт управления должен помогать организации и бизнесу. Потому что если мы не знаем истинных потребностей, краткосрочных и долгосрочных стратегических целей, что действительно важно организации, никакой готовый фреймворк тут не поможет. Внедрять методологию по учебнику, без адаптации, это все равно что лечить пациента «от всего сразу» с надеждой, что-то какая-нибудь из пилюль точно поможет. 

По моему опыту кратчайший способ создать работающую в конкретной организации методологию без лишних бумажек это сфокусироваться только на том, что действительно важно. Готовые фреймворки предлагают нам десяток областей управления, которые необходимо контролировать для достижения успеха проектов, но… Приоритизация этих аспектов, какие из них критически важны, выходит за рамки таких фреймворков. Если у вас на проектах выделенные команды, вам не нужно плодить регламенты для управления ресурсами. Но при этом если цель организации масштабирование, то ключевым аспектом, который нужно железно контролировать на всех этапах проекта, будет сохранение экспертизы.

Чтобы методология работала, а руководство на практике видело, какую пользу ее применение приносит организации и бизнесу, в ее каркасе должны быть только те аспекты, которые наиболее важны.

На вебинаре 22 апреля покажу упражнение, как выделить самые важные области внимания (аспекты) на базе проблем, критериев успеха и ограничений. Регистрируйтесь здесь, чтобы получить ссылку трансляции на емейл.

Попал в зал славы Проектной Ассоциации за мое прошлогоднее выступление, посвященное методу Парацельс ПМ! Всего 2 человека в год получают такую награду😊 Благодарю организаторов, очень приятно👍

Что важнее – методология или люди? Ценности или правила? 

⭐️ На подкасте со Станиславом Беляевым, техническим продактом в Microsoft, подискутировали на эту злободневную тему. А именно: может ли методология сочетаться с гибкостью и свободой принятия решений, а также как влияет наличие ценностей организации на найм сотрудников. 

Станислав поделился своим опытом работы в банке «Точка» – как холакратия в основе системы управления позволяет сотрудникам действовать автономно, при этом соблюдая ключевые принципы и правила.

Что еще успели обсудить:

📌 Когда и почему методология начинает давать сбой?

📌 Ценности организации – ограничение или возможность роста? Можно ли сохранить культуру компании при масштабировании?

📌 Как несоответствие ценностей компании и новых сотрудников может усложнить найм?

📌 Если одна из ключевых ценностей компании это гибкость и адаптация к  изменениям, можно ли эту ценность заложить в основу методологии?

📌 Почему ценности на практике часто не работают?

Смотрите подкаст на Youtube и в ВК видео. Спасибо Станиславу за интересную дискуссию! Если хотите стать гостем нового подкаста, напишите мне в ЛС @Malakhov_Andrey

#подкасты

Как не упустить главное в проекте?

Сегодня хочу поделиться с вами одним элементом метода Парацельс ПМ, который помогает руководителю проекта не терять фокус и не упускать главное в проекте👇

Часто его внимание поглощено разруливанием проблем, контролем сроков и рисков, раздачей пинков команде… И в таком режиме ежедневного тушения пожаров можно легко упустить то, что на самом деле важно организации.

Например, мне, как руководителю и собственнику консалтинговой компании, важно не просто успешно завершить проект, а завершить его так, чтобы заказчик получил вау-эффект от качества работы и захотел продлить с нами работу, начав новый проект.

Но также важно, чтобы об этом вау-эффекте узнали и другие потенциальные заказчики. 

То есть если руководитель проекта обычно мыслит горизонтом «что мы делаем сегодня и завтра, чтобы сроки никуда не поехали», то управленец мыслит совсем иначе – «что мы будем делать дальше, когда этот проект закончится».

И для того чтобы руководитель проекта точно понимал, что важно не только для успешного завершения проекта, но и для успеха организации в целом, на помощь приходят уровни управления.

📶 Уровни управления = масштаб мышления. Они помогают удерживать внимание руководителя проекта, команды и организации одновременно на долгосрочных и на тактических целях при управлении конкретным проектом.

Верхние уровни – это макромасштаб, на котором важно управлять достижением нужных результатов, целей проекта (выгоды, эффекты, польза). Всего того, что важно организации. Например, в моей компании целями каждого проекта являются достижение высоких результатов в двух важных для нас аспектах – удовлетворенность заказчика и развитие бренда. Чтобы заказчик не только захотел продлить работу, но и написал отзыв, а также согласовал написанный нами кейс с его упоминанием. 

Нижние уровни – это микромасштаб, где мы управляем текущими задачи, выявляем проблемы и разруливаем их, минимизируем риски и т.д. Это синхронизация работы команды, управление потоком работ, оперативное реагирование на любые изменения. 

Когда мы контролируем все уровни в нужные моменты времени на проекте, это позволяет не упускать важные результаты для организации и при этом не нарываться на риски. Что значит в нужное время? Например, контролировать успех проекта (верхний уровень) важно на протяжении всего проекта: на стадии инициации мы готовим реестр стейкхолдеров и список требований, во время подготовки планируем ресурсы, по ходу проекта и его завершении делаем отчеты и т.д.

На нижних уровнях, таких как синхронизация команды или быстрое реагирование на риски и изменения, контроль работы критически важен чаще всего только на фазе реализации. И здесь мы работаем с уже более детализированными артефактами, которые не используем на верхних уровнях управления – реестры рисков, ежедневные отчеты о прогрессе выполнения задач и т.д.

Опора на систему из уровней управления помогает не только достигать целей проекта и организации, но и делать это даже в условиях неопределенности и постоянных изменений. Если верхнеуровневые показатели проекта в норме, руководителю проекта не обязательно провалиться на самый нижний уровень и контролировать оперативную работу. Но если требования постоянно меняются или проект буксует из-за влияния внешних факторов, глубина внимания руководителя меняется: он будет находиться на самых нижних уровнях управления, чтобы быстро реагировать на возникающие проблемы.

Подробнее о том, как применять на практике систему из уровней управления, буду рассказывать 22 апреля на бесплатном вебинаре. Коллеги, присоединяйтесь, отвечу на все ваши вопросы🤝

Оно вам надо?

Коллеги, вы просили, и я сделал. Подготовил вопросы, которые стоит задать, чтобы быстро оценить эффективность инструментов проектного управления.

Ответы на эти три вопроса помогут вам понять, что надо улучшить, а от чего отказаться, чтобы перестать мучить сотрудников и не тратить их время на бесполезную бюрократию. 

📌 Вопрос 1. Используется ли этот инструмент на самом деле?

И под использованием я не имею ввиду просто заполнение, потому что так велел проектный офис (и теперь все сотрудники дружно заполняют миллион бумажек, лишь бы от них отстали). 

Под использованием мы должны понимать практическое применение. Если мы ведем реестр стейкхолдеров, используем ли мы его, чтобы спланировать мероприятия по коммуникации с разными аудиториями? Если да, значит, инструмент используется и помогает проекту – он эффективен. А в случае, когда вы один раз заполнили этот реестр, поставили галочку и убрали в архив, то… Ну какая тут эффективность?

Использовать тот или иной инструмент – значит, регулярно обращаться к нему, обсуждать его на совещаниях и формировать план действий на основе той информации, которая есть в заполненном артефакте – реестре, плане, отчете и т.д. 

💡 Если инструмент реально используется, то есть обсуждается для принятия решений по проекту, то его эффективность очевидна.

📌 Вопрос 2. Добросовестно ли мы используем этот инструмент?

Продолжу пример с реестром стейкхолдеров – если вы заполняете его некачественно, с помощью общих формулировок, то, конечно, его использование не будет эффективным. Например, указываете в реестре пользователей системы, вместо более точных формулировок – администраторы системы, операторы данных, владельцы процессов и т.д. От того, насколько точно вы детализировали аудиторию и сформулировали ее описание, зависит качество дальнейшей работы с ней. 

💡 Если вы используете эффективный по своей сути инструмент, но делаете это недобросовестно, его эффективность под большим вопросом.

📌 Вопрос 3. Насколько результат от использования инструмента окупает вложения?

Под вложениями я имею ввиду трудоемкость заполнения какого-либо артефакта. Я часто вижу, как во многих организациях готовят настолько объемный устав проекта… Что уже при одном взгляде на него становится понятно – невозможно применять на практике все данные из этого талмуда. Зачем они тогда нужны?

💡 В этом случае нужно подумать, как упростить и доработать инструмент, чтобы повысить его эффективность – то есть окупить в итоге вложенные силы и время.

И, конечно, при оценке эффективности инструментов стоит смотреть не только на каждый из них в отдельности. Стоит также спросить – а достаточно ли этих инструментов, чтобы уделять внимание важным для нас аспектам? Достаточно ли вести только календарный план, чтобы управлять сроками? 

Потому что в итоге реально эффективны не отдельные инструменты, а их набор – необходимый и достаточный для управления важными аспектами.

Кстати, вот тут я выкладывал гайд, который поможет оценить эффективность вашей проектной методологии в целом.

#управление_проектами

Привычный подход в управлении проектами умер❌ Что дальше?

В этом посте я объяснил, почему привычные нам фреймворки для управления проектами не работают так, как нужно. Одна из причин – описание процессов в виде последовательных шагов это очень ненадежная конструкция, которая на практике чаще всего разбивается о суровую реальность, где всегда что-то идет не так. 

Но проблема даже не в этом. Когда мы действуем согласно описанию шагов, мы упускаем из виду самое главное – проверяемый результат от выполнения каждого шага.

Как я уже писал ранее, недостаточно просто ориентироваться на шаг «Назначить руководителя проекта». Мы должны опираться на результаты – артефакты, которые подтверждают, что Марину Петрову назначали не просто на словах в курилке, а как надо – с закреплением ответственности и выдачей полномочий. 

Если у нас нет артефактов, которые подтверждают ключевые действия, от которых зависит успех проекта, мы своими руками создаем еще бОльшую неопределенность в ходе проекта. Сами растягиваем сроки и раздуваем бюджет только потому, что в моменте не смогли проверить, а все ли мы сделали, что должны были сделать.

Единственный способ минимизировать риски и получать нужные результаты в нужные сроки – применять результатоориентированный подход, вместо процессного. 

💥 Коллеги, приглашаю вас на свой вебинар «Переворот в управлении проектами. Парацельс ПМ: результат вместо процесса», где я подробно и наглядно расскажу о том, как применять мой авторский метод Парацельс ПМ с подходом, ориентированным на результат, для реального, проверяемого и предсказуемого управления проектами.

22 апреля в 19:00 жду вас. Читайте подробную программу и регистрируйтесь здесь, чтобы получить ссылку на трансляцию.

Коллеги, если вдруг вы что-то пропустили, я собрал подборку лучших материалов этого канала за последние три месяца. Читайте, смотрите и делитесь с коллегами🤝

🚀 Посты:

🔹Почему качественная отчетность – залог спокойствия руководителя 

🔹 Найм дорогостоящего специалиста – спасение или выкинутые на ветер деньги? 

🔹 Почему опыт компании важнее опыта одного руководителя 

🔹 Почему вовлечение ключевых руководителей компании жизненно необходимо для реализации важного внутреннего проекта 

🔹 Почему ваши сотрудники играют в молчанку и к каким последствиям это приводит 

🔹 Худший менеджер компании, или что происходит, когда руководитель не может делегировать задачи и проекты

🔹 Почему правила управления проектами не работают 

🔹 Кради художник. Или как нужно заимствовать чужие лучшие практики правильно: часть 1 и часть 2

🚀 Статьи:

🔹 Единственный способ вылезти из ловушки микроменеджмента и запустить автопилот

🔹 Что надо сделать, чтобы проектное управление заработало, а сотрудники начали действовать автономно

🔹 Кейс: как мы настроили и автоматизировали проектное управление для 300+ участников проектов на Jira в Hoff 

А также:

🔹 Запись подкаста с Юрием Проскурней: что такое фреймворки, как они помогают делать проекты и зачем нужны бизнесу

🔥 Кстати, в нашей базе знаний БРИЗ в этом году также появилось несколько новых инструментов:

🔹 Ретроспективные игры - чтобы повысить вовлеченность команды в ретро, создать психологически безопасную атмосферу, направить обсуждение в нужную сторону

🔹 Методика оценки StoryPoints, с помощью которой можно оценить объем усилий и ресурсов, нужных для завершения задачи

🔹 Методика для составления расписания проекта PERT – для планирования и управления проектами, особенно, когда они имеют сложные зависимости

🔹 Метод Дельфи – способствует выработке более точных прогнозов и решений в условиях неопределённости

🔹 Метод критической цепи Critical Chain Method – помогает получить более реалистичное представление о продолжительности проекта, учитывая, что редко всё идёт идеально по плану

#дайджест_PMLogix

Одной мудрости мало

Почему даже самые мудрые и опытные руководители проектов, которые видели за свою карьеру всё и даже больше, могут попадать на самые предсказуемые риски?

Потому что самые предсказуемые риски чаще всего предсказуемы только в конкретной компании. Например, при работе над проектом внедрения корпоративной ИТ-системы выясняется, что команда со стороны заказчика не обладает нужными компетенциями. Те, кто работают в организации уже давно, точно знают, что такое может случиться, как это скажется на успехе проекта и что с этим делать. Но если поставить нового руководителя проекта, пусть даже и очень опытного, но который никогда с подобной ситуацией не сталкивался, то ему придется набить здесь немало шишек.

Так зачем это делать, зачем полагаться на мудрость одного конкретного руководителя, если можно заранее «подстелить соломку» и избавить его от типовых ошибок?

💥 Вместе с Константином Валиотти, генеральным директором ИТ-интегратора «ПолиАналитика», записали подкаст о том, как технология управления проектами помогает в минимизации рисков и не только. Пару лет назад мы с командой PMLogix помогли её разработать, и в этом подкасте Константин поделился, что изменилось и как технология помогла организации вырасти.

Смотрите подкаст на Youtube и в ВК видео.

#подкасты

Какие ваши доказательства?!

В прошлом году я уже затрагивал эту тему, почему на мой взгляд описание процессов в виде шагов не работает, а большинство готовых фреймворков представляет собой декларацию, но никак не алгоритм, помогающий делать проекты быстрее, результативнее и с минимум рисков. 

И вот, что я думаю, почему так происходит👇

Во-первых, шаги – это четкая последовательность, линейный процесс. А в жизни, на реальных проектах, эту последовательность соблюсти практически невозможно: требования постоянно меняются и на какие-то этапы приходится возвращаться. Или наоборот – нужно начинать несколько разных этапов параллельно, если критически важно соблюсти сроки. Например, перейти к реализации, пока этап сбора требований еще в процессе.

И если тут пытаться все сделать по учебнику, по четко выстроенной последовательности шагов, то сделать как надо в итоге заказчику (получить готовый продукт раньше конкурентов), точно не получится. Так зачем нам нужно соблюдать эту последовательность, если на деле она только тормозит? 

Во-вторых, опираясь на описание шагов, инструкцию, а не на проверяемые документы о полученном результате, нарваться на риски становится в разы проще. Почему так? Поясню ниже.

Например, во многих фреймворках шаг «Назначить руководителя проекта» часто описывают в виде его функций – быть ответственным за результат проекта, общаться с заказчиками и тд. Вопрос - как это описание может помочь нам на практике?

Откуда мы знаем, назначили руководителя просто на словах (поставим Иванова на такой-то проект) или все-таки официально, с закреплением ответственности и выдачей полномочий? Очевидно, что в зависимости от того, как именно это было сделано, судьба проекта может быть очень разной.

Внедряемые правила управления не должны лежать в качестве энциклопедии, где описано, что надо сделать на каждом шаге. Они должны работать на практике, быть инструментом для достижения целей как проектов, так и организации, бизнеса в целом.

Поэтому описание шагов, конечно, полезно для общего развития сотрудников и понимания процессов, но на практике нам нужны не шаги, а проверяемые артефакты.

Коллеги, хочу написать пост о том, как оценивать эффективность инструментов. Интересно?

​📣 3 шага, чтобы создать свою технологию управления проектами

Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты, сотрудников вводят в курс нововведений… Но в итоге – пару месяцев «поиграли» по новым правилам и вернулись к тому, что было. Или же сделали вид, что поиграли, а по факту продолжили делать, как делали. 

Потому что технология это, конечно, здорово, но нам вообще-то проекты вывозить надо, а не вашими бумажками заниматься. 

Но правда в том, что без правильной технологии вы и ваши ключевые руководители будете продолжать вывозить, выгорать, тушить пожары. Потому что у вас нет времени объяснять каждому, что же конкретно надо делать, чтобы проекты укладывались в сроки и выделенный бюджет.

Как же создать такую технологию управления, чтобы она реально работала? Чтобы через какое-то время не случилось очередного отторжения – как после неудачной пересадки органа?

💡 Идеально встроиться в днк вашей организации и закрыть ее потребности.

Только в этом случае вы увидите результат от ее применения – возможность делегировать проекты и сложные задачи с уверенностью в результате и четкую, автономную работу сотрудников.

💥 Коллеги, сегодня я подготовил для вас 15-минутное видео, где я не только расскажу, но и покажу на примере реального кейса, как создать такую технологию в 3 шага. 

Чтобы получить видео, переходите в чат-бот.

Читайте о моем методе сборке технологии управления проектами и сложными задачами подробнее по этой ссылке.

​📣 3 шага, чтобы создать свою технологию управления проектами

Я часто вижу, как в организациях пытаются создать свою технологию управления. И почти всегда все начинается оптимистично: руководство дает отмашку, собирается рабочая группа, пишутся регламенты, сотрудников вводят в курс нововведений… Но в итоге – пару месяцев «поиграли» по новым правилам и вернулись к тому, что было. Или же сделали вид, что поиграли, а по факту продолжили делать, как делали. 

Потому что технология это, конечно, здорово, но нам вообще-то проекты вывозить надо, а не вашими бумажками заниматься. 

Но правда в том, что без правильной технологии вы и ваши ключевые руководители будете продолжать вывозить, выгорать, тушить пожары. Потому что у вас нет времени объяснять каждому, что же конкретно надо делать, чтобы проекты укладывались в сроки и выделенный бюджет.

Как же создать такую технологию управления, чтобы она реально работала? Чтобы через какое-то время не случилось очередного отторжения – как после неудачной пересадки органа?

💡 Идеально встроиться в днк вашей организации и закрыть ее потребности.

Только в этом случае вы увидите результат от ее применения – возможность делегировать проекты и сложные задачи с уверенностью в результате и четкую, автономную работу сотрудников.

💥 Коллеги, сегодня я подготовил для вас 15-минутное видео, где я не только расскажу, но и покажу на примере реального кейса, как создать такую технологию в 3 шага. 

Чтобы получить видео, переходите в чат-бот.

Читайте о моем методе сборке технологии управления проектами и сложными задачами подробнее по этой ссылке.

Принимаю поздравления, коллеги. Наконец-то мой канал обогнал фан страницу Андрея Малахова!

Кто я и про что этот блог

Коллеги, в моем канале появилось много новых людей, поэтому предлагаю познакомиться!

Меня зовут Андрей Малахов.
Я и эксперт, и предприниматель, и новатор – разработал и успешно внедряю гибридный метод управления проектами Парацельс ПМ. Собственник и руководитель консалтинговой компании PMLogix. 

Почему я считаю, что меня нужно читать? 

Здесь я делюсь инструментами и решениями, проверенными на личном 20-летнем опыте в управлении проектами и изменениями. А еще рассказываю на примере своих консалтинговых кейсов, как реализовывать масштабные цели, проекты и трансформации с помощью эффективной системы управления проектами и изменениями.

С чего можно начать знакомство с моим блогом:

🔹Почему организации нужна скорость, а не срочность
🔹Если на тебя никто не будет жаловаться, я тебя уволю. Почему руководитель проектного офиса должен быть самым неудобным человеком в компании
🔹Что такое револьверный принцип: как реализовывать важные проекты, когда задачи от заказчика летят нон-стоп

А также:

👉 советую почитать наши #кейсы, в которых я подробно рассказываю о ходе работы, трудностях и методах их преодоления на наших консалтинговых проектах; 

👉 на моем Youtube канале и в ВК видео вы найдете записи вебинаров и подкасты с топовыми российскими экспертами. 

Коллеги, рассказывайте, кто вы, чем занимаетесь и что нравится в моем блоге?

Провел свой авторский двухдневный курс «Проектный офис» на программе «Управление проектами» MBA РАНХиГС. 

Благодарю научного руководителя программы Алексея Владимировича Полковникова за приглашение🤝

Два дня были очень насыщенными: успели пройти все темы, от определения целей, функций, задач проектного офиса до пошагового плана запуска и измерения эффекта его деятельности!

А выше делюсь отзывами слушателей программы. Спасибо за вовлеченность и интересные вопросы!

И еще раз о «лучших» практиках, которые вы пытаетесь внедрить у себя. На скрине выше – комментарий к моей новой статье, где очень хорошо описана ситуация с таким внедрением.

Если реестр рисков всегда заполняется формально, а то и вовсе игнорируется, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять?

Да, вести реестр рисков и заранее прорабатывать меры их устранения это полезная и успешная во многих компаниях практика. Но вы должны трезво оценивать уровень зрелости проектного управления в вашей компании, а потому должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов. 

Если у вас не работает реестр рисков, заведите другой артефакт – пусть это будет реестр проблем. Назовите его как угодно, главное, чтобы его заполняли не формально.

Коллеги, поделитесь, какие инструменты и практики вы пытались внедрить, но они не взлетели?

📣 Почему в одних компаниях проектный менеджмент работает как часы, а в других – только вставляет палки в колеса и мешает руководителям делать проекты?

Потому что в первом случае правила управления создавались с опорой на дистилированный успешный опыт компании, а во втором на «давайте сделаем как у других» или с позиции жестких требований – «врач сказал в морг, значит в морг».

Коллеги, читайте мою новую статью, как создать такие правила управления проектами, которые будут работать, будут приняты сотрудниками и помогут руководству высвободить как минимум 30% своего времени на принятии решений и разруливании кризисных ситуаций.

Стахановцы проектники, а как у вас дела с ментальным здоровьем?

🔥 горю и еду на велосипеде, который тоже горит
👍 ничего, держимся
🥴 у самурая нет цели, только путь

А вот, что говорят те, кто уже приходил ко мне на методологическую экскурсию👆

Пошагово рассказываю на примере одного из кейсов, как создавать такие правила управления проектами, которые решают проблему узких мест в организации и экономят более 30% времени руководства на ежедневном принятии решений и микромененджменте.

Коллеги, экскурсия бесплатная, но в этом месяце у меня есть только 2 места.

Для записи напишите мне в ЛС @Malakhov_Andrey

Продолжаю тему: как правильно заимствовать лучшие практики? Расскажу на примере одного недавнего кейса👇

Во время разработки единых правил управления мы с заказчиком определили три основных типа проектов в компании. Все они одинаково важны, но цели различны: например, для коммерческого проекта наиболее важны сроки реализации, маржинальность и удовлетворенность заказчика, а для внутренних проектов по совершенствованию процессов – приживаемость результатов. 

Что дальше? Мы посмотрели, какие инструменты и практики уже применялись в компании для достижения этих целей. Что показало свою эффективность, а что оказалось бесполезным и от этого стоит отказаться. 

Если раньше реестр рисков всегда заполняли формально (риски нарушения сроков, превышения бюджетов и неудовлетворенности заказчиков), а то и вовсе игнорировали, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять? Должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.

И вот когда мы разобрались, что можно оставить, а от чего нужно отказаться вовсе… Мы начали смотреть на то, что можно улучшить. И именно на этом шаге полезно обратиться к внешнему опыту, чтобы понять, что может подойти.

Например, если мы говорим о внедрении новой корпоративной ИТ-системы, то в некоторых компаниях в рамках чендж-менеджмента успешно применяют индивидуальные сессии с сотрудниками для коучинга и сбора обратной связи. Но если в вашей компании руководители, проводящие подобные сессии, не обладают необходимыми навыками, а встречи тет-а-тет для сбора обратной связи не сочетаются с корпоративной культурой, то лучше пока забыть про эту практику.

Выводы: используйте чужие лучшие практики только если они соответствуют контексту и культуре вашей компании, но даже в этом случае АДАПТИРУЙТЕ ИХ, иначе эти лучшие практики станут для вас худшими.

Кстати, то же самое происходит с готовыми фреймворками, которые многие пытаются впихнуть в организацию, не адаптировав под ее контекст. 

❗️Коллеги, если хотите посмотреть, как создаются правила управления проектами с адаптацией инструментов из других фреймворков под культуру компании, приглашаю вас на методологическую экскурсию🔥

Пошагово расскажу и покажу на примере одного кейса, как мы разрабатывали правила, используя имеющийся опыт организации и внешние практики.

Чтобы записаться на экскурсию, напишите мне в ЛС @Malakhov_Andrey

Никого вам не напоминает?😅

Кради как художник🥷

Каждый руководитель, осознавший необходимость единых правил управления проектами, рано или поздно приходит к мысли: «А может, посмотреть, как работают другие и внедрить то же самое у нас?» Ведь успешные компании уже выстроили свои процессы, значит, их можно просто скопировать?

Но это работает не совсем так, и ниже я поясню, почему слепое копирование чужого опыта – плохая идея.

Все лучшие практики являются лучшими только потому, что они хорошо работают в конкретной компании и учитывают корпоративную культуру, внутренние процессы, правила взаимодействия. Сейчас часто даже «лучшие практики» переименовывают в «хорошие» (имея в виду, что не стоит их слепо копировать).

👉 Например, в одной компании процедура согласования документов занимает 3 месяца – для них это норма, встроенная в бизнес-процессы. Для вас такие сроки – катастрофа, которая парализует работу. 

👉 В другой компании регламенты и бизнес-правила создаются в электронной доске (типа Miro) или презентациях – быстро, удобно, наглядно. Но у вас такой формат не работает, потому что презентация не считается формальным документом – регламенты должны быть подготовлены в соответствии с внутренними стандартами предприятия и правилами документооборота.

Я не говорю о том, что не нужно смотреть, как делают другие. Но если вы хотите создать единые правила управления проектами, то опираться вам в первую очередь нужно не на чужой опыт, а на свой. И только после этого смотреть, что есть у других, что можно использовать у вас. 

Как правильно заимствовать лучшие практики? Расскажу в следующем посте на примере одного недавнего кейса. Если интересно, дайте знать🔥

Почему в Макдональдсе при высокой текучке качество остается неизменным?

Все знают, что работа в Макдональдсе – это временное трудоустройство. Однако несмотря на высокий уровень текучки, это никак не влияет на качество продукта.

Почему? Система работы выстроена таким образом, что здесь нет незаменимых сотрудников. Люди приходят и быстро обучаются внутренней технологии, а процесс производства остается стабильным, независимо от того, кто стоит за кассой или у плиты.

Да, управление проектами это вам не котлеты жарить, но… В любой успешной компании, независимо от отрасли, стабильность качества достигается за счет технологии. В нашем случае – это единые правила управления проектами, которые позволяют:

✅ подстраховаться от ухода ключевых сотрудников и потери знаний

✅ ускорить процесс онбординга новых руководителей проектов

✅ быстро передать проект джуниору, если опытного руководителя нужно поставить на более важный, крупный проект

Но самое главное это то, что единые правила помогают руководству высвободить время и энергию, которые приходится тратить на принятие решений. Без них приходится каждый раз проходить весь цикл принятия решения с нуля, а именно:

👉 понять, в чем проблема и какие у нее последствия
👉 выбрать подходящее решение из множества возможных альтернатив
👉 договориться с заинтересованными сторонами, чтобы избежать сопротивления
👉 внедрить решение и убедиться, что оно работает

Например, что делать, если уходит ключевой сотрудник, как "вытащить" знания из его головы по проектам, которые он вел? Можно каждый раз собираться и тратить время на поиск решения, а можно – следовать правилам, которые созданы для такой ситуации:

🔹 когда руководитель проекта достигает определенного уровня, "прикреплять" к нему младшего сотрудника для передачи опыта

🔹 по завершении проекта организовывать презентацию кейса с отсылками на все необходимые материалы

🔹 внедрять чек-листы по передаче дел, которые сотрудник должен заполнить при увольнении и т.д.

Потому что правила – это и есть уже принятые решения по действию сотрудников в конкретных ситуациях.

Что важно учитывать при разработке единых правил управления?

Главная ошибка – копировать чужие лучшие практики или ориентироваться на популярные стандарты, не учитывая специфику своего бизнеса. Правила должны основываться на вашем реальном опыте и об этом подробнее я расскажу в следующем посте.

Когда в компании нет единых правил управления проектами и тебя дергают 24/7…

Да не работают эти ваши правила управления😡

Действительно, вы и сами наверняка видели такое не раз во многих организациях – придумали и внедрили какие-то новые правила, шаблоны, документы… Сказали – а теперь, Ваня, заполняй наш новый реестр рисков и все будет хорошо. 

Ваня, конечно, пару раз заполнил для вида, но… Надолго его не хватило. Потому что ему надо заниматься реальными делами, спасать проект, искать ресурсы, заниматься интеграциями, а не этой бесполезной возней с бумажками.

💡 Ваши новые правила управления проектами никогда не заработают и вы никогда не сможете слезть с ручного управления, пока вы мыслите категориями требований. Пока вы требуете заполнения каких-то форм, которые надо заполнить. Кому надо? Зачем надо?

Во вчерашней статье я затронул такое понятие, как аспект. Наша задача не просто определить важные области управления и инструменты для их контроля, но и договориться о них как на уровне менеджмента, так и на уровне исполнителей. 

Например, в рассматриваемом кейсе из статьи аспект сохранения и передачи экспертизы важен прежде всего для менеджмента, но не для команды. И если команда не будет понимать, почему важно заполнять все эти бумажки, реестры для передачи знаний от более старших коллег новичкам, как это поможет лично им в работе и как повлияет на успешность их проектов в будущем, никто не будет этого делать.

Договариваясь об аспектах на уровне руководства и сотрудников, мы договариваемся о том, что для нас действительно важно, что мы не придумываем какие-то правила только ради правил (таких регламентов полно в любой организации). Их необходимость железобетонно обоснована, это не прихоть руководства и не бестолковая бюрократия.

❗️Что еще нужно учитывать: правила управления должны стать единой системой, живым организмом, который может развиваться вместе с организацией. В такой системе все элементы связаны друг с другом. Если у нас есть артефакт, значит должно быть событие, где он используется или создается. Если мы убираем артефакт, то должны проверить, а сможем ли мы без него уделять должное внимание выбранному аспекту и при этом не нарваться на риски. 

Например, если мы формируем календарный план проекта, то мы используем его во время обсуждения на встречах. Если его убрать, то сможем ли мы без него обсудить состояние проекта, отклонения, зависимости, текущий прогресс? Сможем ли мы уделять достаточное внимание срокам проекта?

Когда есть целостная система из взаимосвязанных элементов, то мы всегда можем что-то убрать и добавить более релевантное потребностям организации.

Но когда у нас есть просто статичная конструкция из правил, рано или поздно некоторые из них устареют (обычно за 1-3 года), и, если их не изменить, то они будут снова восприниматься как бюрократия.

Единые правила управления проектами – это договоренности, чему мы уделяем внимание (аспекты) и с помощью чего мы это делаем (артефакты и события). А также когда и с какой регулярностью мы это делаем и кто отвечает за их выполнение.

Правила важны, но не менее важен процесс, в рамках которого они создавались. Согласны?

Единственный способ вылезти из ловушки микроменеджмента и запустить автопилот

Все верят, что если найти правильных людей или правильно обучить действующих сотрудников, то вопрос менеджмента, делегирования сложных задач и проектов будет закрыт навсегда. Что можно сбросить груз постоянного контроля на пару надежных руководителей и, как минимум, высвободить время для решения задач своего уровня, а, как максимум, начать больше уделять времени семье или личному развитию.

Но это так не работает и никогда не заработает.

Суровая правда жизни такова, что пока не будут созданы нужные условия, вы, как руководитель организации, будете продолжать все вывозить на себе и делать работу не своего уровня. 

В этой статье рассказываю о единственном работающем способе, как выбраться из ловушки микроменджмента и какие шаги на примере одного кейса вы можете предпринять уже сейчас.

Сильные сотрудники – не повод расслабляться

Если вашим сотрудникам постоянно приходится объяснять, что и как надо делать, вы всегда будете по уши в текущих проектах.

Но даже если у вас работает несколько надежных, опытных, профессиональных сотрудников, которые не нуждаются в контроле... Вы все равно будете по уши в текущих проектах 🤡

Не так давно ко мне обратился заказчик с проблемой: "Я не могу делать столько проектов, сколько нужно для роста компании, потому что все завязано на мне и трех ключевых руководителях проектов."

При этом у компании:

✔ Достаточно отраслевой экспертизы
✔ 20 лет на рынке и огромный опыт
✔ Десятки успешных кейсов

Но:

🚩 Ключевые руководители уже перегружены. Они ведут по 2-3 проекта одновременно и физически не могут взять больше.

🚩 Каждый действует по-своему, опираясь на свой опыт и ожидания заказчика. Когда все знания только в голове у нескольких экспертов, то передать их новым сотрудникам очень сложно, и процесс натаскивания может растянуться на годы.

🚩 Генеральный директор боится потерять контроль. Он понимает, что бизнес зависит от нескольких людей, и вынужден глубоко погружаться в детали идущих проектов, опасаясь, что кто-то уйдет.

В итоге: старички не могут вывезти все, новички не тянут без помощи старших коллег и долго входят в курс дела, а руководство продолжает тонуть в операционке.

Что мы сделали в этом кейсе, как помогли руководству выбраться из ловушки микроменеджмента, а также с чего начинается переход на новый уровень в делегировании сложных задач и проектов – расскажу в статье, которая выйдет уже на этой неделе.

Худший менеджер в компании

Продолжаю тему предыдущего поста – когда руководитель берет на себя чужую работу, часто он не может делать ее качественно. И выполняя роль рядового проектного менеджера, он становится… худшим проектным менеджером в компании. Почему?

👉 Во-первых, руководитель не может и не должен владеть всеми знаниями, последними технологиями и инструментами для ведения проекта. И часто, вмешиваясь в ход проекта, чтобы понять, что там происходит, он может предлагать не самые эффективные решения.

👉 Во-вторых, ему вообще все это неинтересно. Ему хочется заниматься “своими” делами, развитием, внедрением инноваций в процессы, но приходится делать не свою работу – через силу, с единственной мотивацией “если я не сделаю, то никто не сделает”.  

👉 В-третьих, когда ежедневно приходится вникать в десятки задач разного уровня – от написания технических требований к внедряемой системе до разработки стратегии нового направления бизнеса… Фокус внимания размывается и страдает качество выполнения всех его задач.

💡 А еще, так как он не обладает полной картиной происходящего на проектах и в силу ограниченности времени, он становится чайкой-менеджером: неожиданно прилетает, наводит много шума и улетает. Он хочет все быстро порешать и часто может предлагать варианты действий, с которыми никто не согласен, но и спорить тоже не хочет. В итоге команда остается в полном параличе без способности делать что-либо самостоятельно и организованно.

Вот, что происходит, когда мы, как руководители организаций, занимаемся задачами не своего уровня, потому что нам не на кого положиться.

Но даже если в вашей компании есть надежные люди, это еще не значит, что вы сможете легко выбраться из ловушки микроменеджмента. Продолжим эту тему завтра👍

Быть костылем для команды, а не руководителем

В прошлом посте я писал, почему ваши сотрудники могут скрывать правду о происходящем на проектах. И когда такое случается, очевидно, что положиться на них трудно – вам приходится не только все перепроверять, но и тратить свое время на то, чтобы каждому объяснить, что и как нужно делать. 

В итоге руководитель превращается в костыль для команды, без которого рабочие процессы начинают буксовать. Он постоянно поддерживает сотрудников, берет на себя чужие задачи и разруливает все вручную:

👉 объясняет, как общаться с заказчиком проекта, как предотвратить и уладить конфликт;

👉 договаривается с  руководителями других подразделений о выделении ресурсов;

👉 напоминает, что ведение календарного плана — это требование, а не прихоть;

👉 следит, чтобы о нехватке людей или слабом составе команды сообщали заранее, а не когда уже все сроки сорваны;

👉 сам пишет требования и разрабатывает архитектуру, когда дело касается внедрения новой сложной системы.

Может казаться, что при таком положении дел ситуация под контролем, но на самом деле это ловушка, которая:

❌ лишает руководителя времени на выполнение задач его уровня: формирование планов развития, разработку новой продуктовой линейки, внедрение инноваций в процессы, изменение системы мотивации и т.д

❌ делает его узким местом

❌ ограничивает возможность реализации масштабных изменений и, как следствие, развитие компании

Что делать? Отправить сотрудников на обучение или заменить на других, найти новых – более профессиональных и опытных?

Однако это чаще всего слабое решение проблемы. Даже при наличии крутых сотрудников есть свои риски, и в следующем посте поговорим, какие именно.

Про безответственность и игру в молчанку🫢

Знакома ли вам ситуация, когда из-за того, что вы не можете положиться на своих сотрудников, вам приходится все постоянно контролировать, а то и самому делать работу за них? Ведь без вашего участия точно что-то пойдет не так, и это "что-то" окажется для вас большим сюрпризом.

Так почему вы узнаете о проблемах последним? По какой причине ваши сотрудники не предупреждают вас о рисках, чтобы заранее принять нужные меры? Что это – безответственность или вопиющая некомпетентность?

💡Одна из причин такого поведения – нежелание говорить правду, и вот, почему:

👉 в вашей организации может процветать политика замалчивания, и сотрудники просто боятся говорить о проблемах. Боятся, что их сделают крайними и "повесят" еще десяток задач сверху для разруливания ситуации.

Поэтому наблюдая за тем, как проект улетает в пропасть и приближается неминуемая "жопа", они будут надеяться, что справятся сами.

👉 ваши сотрудники могут не понимать планки (требований) в управлении проектами, к которой нужно стремиться.

Например, считать, что вести календарный план необязательно, ведь все сроки прописаны в договоре с подрядчиком, а отставание проекта на 1-2 месяца от планового срока из-за задержки в готовности кросс-системных интеграций – это норма и "так всегда". Потому что они ориентируются только на предыдущий опыт в реализации подобных проектов. И если по их мнению все норм, зачем лишний раз светиться перед руководителем?

👉 ваши сотрудники могли изначально подписаться под заведомо нереалистичными планами проекта, поэтому любое отклонение – также норма.

В одном из наших кейсов у заказчика, крупной девелопреской компании, была похожа проблема: чтобы подстраховаться и соблюсти внешние сроки сдачи объекта в эксплуатацию, создавался внутренний план с большим сдвигом влево. Под этим планом все подписывались, но никто в него не верил и даже не старался выполнить. В итоге все молча отставали, не предупреждая о невозможности выполнить план, ведь "это и так понятно".

Страх остаться виноватыми, непонимание требований к качеству управления и нереалистичные планы – то, почему вам могут не говорить всей правды о происходящем на проекте.

К каким последствиям приводит эта игра в молчанку? Буду разбирать в следующем посте🔥

🔥 Коллеги, если вы тоже любите цифры и исследования, то рекомендую канал Дмитрия Ирешева.

Дима – руководитель проектного офиса 5 Post, автор статей и временами спикер на тему проектного и продуктового управления.

Ели вы любите интересные факты, статьи, книги и новости, тогда вы точно найдете, что почитать на этом канале.

Ниже делюсь материалами, которые мне понравились:

🔹 Свежие слухи о PMBOK8
🔹 Каждый десятый разработчик в ИТ-гигантах не работает
🔹 Сотрудники мультимиллионеры NVIDIA
🔹Эволюция Доверия - бесплатная онлайн игра
🔹 Подборка нейронок на все случая жизни

P.S. А еще на канале Димы есть ссылки на полезные в работе (и не только) нейронки👍

🔹 Пирамида Маслоу – фреймворк или методология? 
🔹 Где заканчивается фреймворк и начинается методология? 
🔹 Является ли жизненный цикл проекта самодостаточным фреймворком для управления?
🔹 Почему Agile-манифест это не фреймворк?
🔹 Как использование фреймворка помогает бизнесу вести проектную деятельность и внедрять изменения, а в каких случаях он вредит?
🔹 Ламборгини или Феррари? Или почему не надо сравнивать проектный, продуктовый и чендж-менеджмент.

💥Эти и другие темы обсудили в нашем подкасте с Юрием Проскурней. Что такое фреймворки управления проектами и изменениями, чем они отличаются от методологий и для чего они нужны бизнесу – смотрите на Youtube и в ВК видео. 

Спасибо Юрию за интересную беседу🤝

#подкасты

Главное успеть поздравить и пожелать...

... себе на День рождения:

- Энергии и здоровья, чтобы руки не опускались, когда так хочется сдаться или отложить на завтра

- Непреклонности - доводить классные идеи до реализации, а не лелеять в голове и не бросать на полпути

- Ценить, беречь и заботиться о близких, дорожить отношениями

- Найти девушку, с которой мы сможем создать и разделить яркие моменты жизни

- Смелости - делать новое, непривычное, страшное

- Мудрости - заниматься только тем, на что могу повлиять

- Решительности - действовать, а не тонуть в анализе альтернатив

- Масштаба - думать о том, как изменить мир, а не просто срубить бабла

- Сфокусированности - не распылятся, не браться сразу за много дел

- Терпения - не дергаться, если сразу не получилось

- Принципиальности - делать только то, что соответствует принципам, не идти на сделку с совестью

- Счастья - ценить самые простые моменты, когда ешь вкусную еду, вдыхаешь свежий воздух, общаешься с приятными людьми.

И этого более чем достаточно 😅

💥 Почему фреймворки управления проектами и изменениями мастхэв для их успеха

Мы с Юрием Проскурней, как авторы собственных фреймворков по управлению проектами и изменениями, решили собраться и поговорить на эту злободневную тему. 

А именно: 

✔️чем эффективны подобные фреймворки и от каких проблем в организации и бизнесе они спасают
✔️можно ли с помощью фреймворка раз и навсегда делегировать реализацию проектов и сложных задач
✔️как подобрать нужный фреймворк, чтобы проекты реализовывались, а изменения внедрялись без вашего постоянного участия?
✔️что изменится в организации и бизнесе, если внедрить подходящий фреймворк?
✔️чем отличаются наши, отечественные фреймворки от международных? Каковы плюсы и минусы в применении в российской реальности?

Будет интересно! Скоро поделимся записью подкаста.

У Юрия, кстати, есть телеграм канал, где он делится полезными материалами на тему управления изменений, поэтому советую на него подписаться🤝

Почему важно вовлекать ключевых сотрудников с самого начала?

Не так давно я делился нашим кейсом по настройке и автоматизации проектного управления на Jira для 300+ участников проектов. Это была большая сложная работа, цель которой – обеспечить прозрачность в управлении проектами и портфелем для всех ролей, от исполнителей до бизнеса.

По сути с помощью создания десятков дашбордов в системе для каждой проектной роли мы выстроили вертикаль от стратегических целей бизнеса до каждого отдельного проекта.

Но самым сложным были не технические настройки, не адаптация системы к нужным бизнес-сценариям и даже не необходимость развертывать очередную фичу в ночное время, пока никто не пользуется системой.

🔧 Самым сложным в этом кейсе был этап формирования требований. Потому что:

🔹 ключевые эксперты, участие которых критически важно, были перегружены, и им было трудно выделить время;

🔹 было важно не только сформировать требования, но и донести до каждого руководителя каждого подразделения, для чего в его область работы добавляются те или иные изменения (необходимость отчитываться по срокам, привязывать реализуемые задачи, списывать трудозатраты и т.д.)

Это, конечно, было не просто, но самое главное – приводило к большому количеству доработок, итераций, и было непонятно, когда мы сможем завершить проект. В итоге, уже ближе к концу, я организовал несколько очных сессий (до этого работа велась онлайн) и путем нескольких итераций с ключевыми руководителями доработали систему.

💡 Главная мысль: когда дело касается большого, сложного, нетипового проекта, практически невозможно с самого начала определить 100% всех требований и четкий образ результата, и это нормально. Потому что понять, что именно нужно и как что должно работать, можно только путем разумного количества итераций в режиме постоянной обратной связи. А это, в свою очередь, возможно только при вовлечении ключевых экспертов (и наличии у них выделенного времени).

👉 Нужная степень вовлечения нужных людей в нужные этапы проекта = снижение риска, что ваш проект растянется на несколько лет. Согласны?

Как загубить проект в самом начале

Представьте, что вы собираетесь отправиться в длительное путешествие на автомобиле. Вы тщательно проверили машину и заполнили бак топливом. Но по какой-то причине вы решаете не использовать навигатор — например, потому что думаете, что знаете маршрут наизусть или рассчитываете следовать указателям на дороге. Однако именно из-за этого вы тратите много сил и времени на ненужные пути, попадаете в пробки и не приезжаете в нужное время в нужное место. То есть результат вашего путешествия совсем не тот, который вы ожидали.

В управлении проектами подобные ситуации также происходят, когда на начальном этапе вы сформировали неточный, неполный образ результата проекта. Это обычно приводит либо к тому, что сроки проекта сильно сдвигаются из-за бесконечного уточнения требований, либо вовсе к отсутствию нужного, полезного результата внедрения, позволяющего быстро окупить вложенные инвестиции.

💼 Как-то раз я внедрял ERP-систему для производственного предприятия. Одной из главных целей внедрения было выполнение плана производства за счет повышения мотивации работников на выполнение этого самого плана.

Но заказчик подходил к внедрению системы только со стороны функциональности программного продукта, т.е. того, что и как должно работать в будущей системе. И в образе результата была упущена управленческая отчетность – она должна была быть создана уже после завершения основного проекта. То есть по сути было упущено то, ради чего вообще внедряли систему – автоматизированной отчетности с достоверными данными для анализа и принятия нужных управленческих решений.

Когда я разработал и внедрил отчетность по отслеживанию брака, ее сразу же стали применять для повышения качества производства. Директор по производству был в полном восторге, даже несмотря на то, что отчет “считался” несколько часов.

Даже один такой сформированный отчет для отслеживания брака помог компании улучшить и оптимизировать производство. Но если бы создание и внедрение отчетности были бы изначально включены в образ результата от проекта внедрения, компания начала бы получать эффект сразу же, не растягивая разработку и внедрение отчетности еще на пару лет.

Как видите, формирование четкого образа результата проекта помогает намного более реалистично оценивать его трудозатраты и быть уверенными, что внедрение завершится в нужные сроки и вы начнете получать нужный эффект. 

Продолжение следует🔥

Что самое важное при делегировании проекта?

Возможность видеть достоверные данные по его прогрессу, чтобы заранее отслеживать негативные тенденции и своевременно принимать нужные решения. Только оперевшись на цифры, которые реально отображают происходящее на проекте, можно избежать пожарных ситуаций и необходимости снова все разруливать самому.

👉 В прошлом году у нас был очень необычный кейс. Перед заказчиком, крупнейшим российским банком, стояла задача реализовыть программу ИТ-трансформации. А именно: перейти с западного ПО на свой собственный продукт, разработку которого необходимо завершить в ближайшие несколько лет.

И вот здесь начинается самое интересное. В разработке, которая ведется по Agile, участвует несколько команд от каждого функционального подразделения банка. А сам продукт – с большим количеством кросс-системных интеграций, искусственным интеллектом и сложной архитектурой, которая должна соответствовать различным бизнес-процессам банка. При этом код частично пишется с нуля. Регулярно возникают дополнительные требования по функционалу и работа превращается в бесконечность без возможности что-либо спрогнозировать.

Занимаясь этим продуктом уже год, разработчики все еще не понимают образ конечного результата, итогового функционала. При этом руководству критически важно отслеживать прогресс по проекту, так как есть ограниченные сроки, которые не получится подвинуть. А прогресс разработчики никак не могут подтвердить – можно довериться только их экспертной оценке.

В итоге ситуация максимально критическая: в продукт уже инвестированы миллиарды рублей, но все еще непонятно, будет ли вообще получен результат в указанные сроки. Риски для заказчика слишком высоки, чтобы полагаться только на честное слово разработчиков.

🔥 Как мы помогли заказчику с этой нетривиальной задачей, организацией контроля и планирования прогресса на проекте в Agile среде, буду делиться в следующих постах. Интересно?

#кейсы

Коллеги, делюсь важной и долгожданной новостью🔥

Мы опубликовали один из самых масштабных кейсов в России по настройке и автоматизации процессов управления проектами на Jira.

👉А именно: для 300+ участников проектной деятельности в компании Hoff.  

ИСУП должна была закрывать потребности десятка подразделений, участвующих в проектной деятельности:

🔹 топ-менеджменту нужна прозрачная картина о том, в каком состоянии находятся их проекты и продукты, информация об общем статусе по портфелю на текущую дату и прогноз на конец года;

🔹 проектному офису — понимание, какие проекты предложить к запуску в первую очередь в зависимости от стратегии, приоритетов и наличия ресурсов, каковы актуальные статусы и сроки по каждому из проектов;

🔹 ресурсным руководителям – информация о текущих проектах и их сроках, а также о проектах, которые стартуют в ближайшее время, чтобы планировать загрузку ресурсов;

🔹 руководителям проектов – инструменты для отслеживания этапов проектов, сроков и отклонений;

🔹 отделу бюджетирования – информация, как и куда расходуются ресурсы и соответствует ли план факту, и прочее.

За 8 месяцев работы моя команда PMLogix совместно с командой Hoff и Hoff Tech провели масштабную работу, включающую разработку более 20 дашбордов для всех ролей проектной деятельности. 

Коллеги, читайте кейс целиком на нашем сайте.

Кстати, 4 года назад я проводил вебинар на эту тему «Как использовать Jira для управления проектами», также советую посмотреть.

#кейсы

Делегируй-не делегируй, но проверять и принимать решения по проектам все-таки придется. Вопрос только в том – будет ли это легко, быстро и удобно или же долго и мучительно?

Если хотите высвободить свое время, то внедряйте прозрачную, понятную отчетность. Она дает возможность опираться на ДОСТОВЕРНЫЕ данные по проекту и быстро принимать НУЖНЫЕ решения по ВАЖНЫМ вопросам. А именно:

🔹 не тратить время на многочасовые совещания в попытках разобраться, что же на самом деле происходит в проектах

🔹 не погружаться в тяжеловесные презентации от сотрудников и ненужные вам детали, отвлекаясь от важных задач развития

🔹 заранее видеть отклонения на проектах и принимать своевременные меры своего уровня, не доводя ситуацию до критической

🔹 понимать вероятность получения запланированных эффектов с учетом уже полученных результатов

🔹 иметь наглядную картину всего происходящего без постоянного пинания сотрудников

💡 Конечно, отчетность идет в связке с регулярными встречами. Без встреч вы можете не узнать, что какие-то планы проектов нереалистичны, что кто-то кого-то недопонимает, что есть незадокументированные риски. То есть если отчеты показывают вам цифры и факты, то встречи – это способ почувствовать, что происходит в проекте такого, что не умещается в отчеты.

Коллеги, откликается вам эта тема?

Компания мудрее одного человека

Вчера большинство из вас распознало истинную причину проблемы в нашем кейсе👇

Если ваши сотрудники, даже самые опытные профи, ведут проекты исходя из собственного опыта, вы все равно никогда не сможете полностью отдать управление проектами под их ответственность. Потому что любой, даже самый богатый профессиональный бэкграунд руководителя проекта ограничивается его личным опытом, а не опытом компании. Поясню, что это значит.

Например, взаимодействие с заказчиками. С кем-то оно происходит неформально, без фиксации результатов, с устными договоренностями. С кем-то постоянно возникают сложности – то доступы не предоставили, то согласование документов затянули… 
А с кем-то требуется максимально бюрократизировать взаимодействие, терпеливо добиваться нужных согласований и предоставлять детальную информацию по проекту. 

Все это совершенно разный опыт взаимодействия. 

И, получается, что сталкиваясь с разными ситуациями, руководитель проекта ограничивается лишь тем опытом, который есть у него. А если этого опыта не хватает, то он начинает изобретать велосипед. Это дорого для компании.

То же самое можно сказать и о специфике проектов. Когда руководитель переходит с одного проекта на другой, то он может столкнуться со сложностями, которые ранее не встречал в своей практике. Потому что опыты ведения проектов поддержки, внедрения или собственной разработки тоже сильно различаются.

А еще этот регулярный менеджмент… 
Опытные руководители проектов не любят заниматься регулярными, нужными вещами, потому что они привыкли держаться фокус на решении конкретных проблемных ситуаций. А не на тех профилактических действиях, которые помогают их предотвратить. Но в итоге… Планы не ведутся, регулярные встречи по проекту превращаются в переписку, а отклонения по проекту эскалируются только тогда, когда заказчик начинает жаловаться и писать официальные письма о расторжении договора.

Когда каждый руководитель проекта действует исходя их собственного опыта, самостоятельно решая, как ему взаимодействовать с заказчиком в каждом конкретном случае, пытаясь найти способы устранения проблемы на проекте и забивая на профилактические действия… Собственнику или руководителю организации приходится постоянно действовать в ручном режиме и контролировать все и всех. Давать обратную связь, следить за удовлетворенностью заказчиков, отправлять руководителя «посмотреть», как они эту проблему решали на другом проекте…

💡 Ваша задача не превратить каждого руководителя проекта в самого опытного, универсального и мудрого управленца (это невозможно). А сделать так, чтобы каждый из них получил дозу дистиллированного опыта компании. 

Потому что опыт компании богаче, чем опыт одного человека, и учитывает:

🔹 разновидность проектов в компании и проблем, которые могут на них возникать

🔹 успешные практики и инструменты, которые хорошо работают именно в вашей компании

🔹 специфику компании, отрасли, корпоративной культуры, скорости принятия решений и всего того, что влияет на реализацию проектов, и т.д.

👉 Как минимум это позволит перестать вашим руководителям проектов наступать на одни и те же грабли и постоянно сталкиваться с проблемами, которые уже возникали 1000 раз. 

👉 Как максимум – вы будете уверены, что вас не будут дергать по каждому поводу. Потому что эти поводы будут минимизированы. А еще сделаете крепкий фундамент для быстрой эволюции новых сотрудников, которым не нужно будет расти и набираться опыта методом проб и ошибок.

Сегодня предлагаю вам сыграть в игру. Я вам расскажу об одном нашем кейсе, а вы попробуете предположить, в чем настоящая причина проблемы👇

Дано: ИТ-компания средней величины, которая занимается консалтингом в области автоматизации бизнес-процессов. Компания зрелая, давно заняла свою нишу, сотрудники – высококвалифицированные эксперты, работающие здесь много лет. Справляются со своей работой без каких-либо регламентов, все держится на неформальных связях.

Несмотря на то, что у ключевых сотрудников большой опыт и широкий кругозор в области управления проектами, часто проекты все равно завершаются с непредсказуемыми результатами и сроками, а некоторые заказчики остаются недовольными.

Собственнику при этом приходится постоянно быть включенным в проекты, откладывая свои задачи по развитию и масштабированию компании.

❓Как считаете, в чем здесь может быть проблема?

Почему даже при наличии надежных, профессиональных руководителей не получается достигать целей проектов без постоянного вмешательства собственника?

Ниже для вас я подготовил опрос, а правильный ответ выложу завтра🙂

Почему найм крутых, дорогостоящих руководителей проектов вам не поможет?

1️⃣ Во-первых, ваши проекты уже идут, а поиск высококвалифицированного специалиста может занять месяцы. А еще это весомые инвестиции без какой-либо гарантии. 

Когда-то давно в роли руководителя портфеля проектов я отвечал за проект по развертыванию банкоматной сети, и я долго искал нужного спеца, нашел, но… В день выхода он просто не вышел на работу – то ли у него поменялись планы, то ли он получил более интересное предложение. В итоге нам пришлось ставить на проект менее опытного, но более доступного сотрудника. Проект мы, кстати, в итоге успешно реализовали. 

Многократно у своих клиентов я наблюдал истории, когда в штат искали проектного методолога, тратили огромные деньги и месяцы, но так и не смогли найти никого подходящего. Или же найденные кандидаты в итоге принимали более интересный оффер.

2️⃣ Во-вторых, наверное, вы тоже сталкивались с такими ситуациями, когда найти опытного, крутого руководителя проекта удавалось, но… Спустя пару месяцев он уходил по собственному желанию.

Почему так происходило? 

Часто новому, высококвалифицированному специалисту трудно вписаться в компанию, потому что он привык к упорядоченному менеджменту. Ему с трудом даются мутные корпоративные правила игры, в которых он должен тратить огромное количество времени на согласование нужных ему решений, вместо того, чтобы заниматься интересными задачами. И он понимает, что профессиональный рост, за которым он и пришёл в компанию, здесь ему недоступен. И разгребать все эти авгиевы конюшни бюрократии с бесполезными телодвижениями ему совсем не хочется. 

Крутые профессионалы не задержатся в компании, если понимают, что здесь снижается их эффективность и они не могут работать на 100% от своей мощности. Не могут быстро реализовывать проекты, чтобы пополнить свое портфолио и получить признание в отрасли.

Если в вашей организации уровень бедствия в плане менеджмента высок, то найм нового, дорогостоящего профессионала – выкинутые на ветер деньги.

❓А что, если у вас уже работают не только высококвалифицированные, но и надежные руководители проектов, которые точно проработают в компании много лет и никуда не сольются? Является ли это залогом того, что вы можете расслабиться и полностью делегировать им все проекты?

Нет. Завтра будем разбираться, почему.

Интересно?

Доверять нельзя никому❌

Часто от своих клиентов, которые не могут полностью делегировать проекты своим менеджерам, я слышу примерно следующее: «Да как им доверять? Если их постоянно не контролировать, то всегда будут возникать проблемы».

А дело тут совсем не в доверии. Вы можете делать успешные проекты без постоянного вмешательства и доверия к сотрудникам.

Так в чем же секрет? Может, нанять несколько крутых, дорогостоящих менеджеров и расслабиться?

👉 Почему это не поможет, какой вред вы приносите организации из-за невозможности делегировать проекты и как начать это делать – читайте в моей статье.

Бесполезные совещания и пустая отчетность

Если вы все вывозите на своем личном ресурсе, чтобы не получать негатив от заказчиков, обратите внимание на важную область управления проектами – отчетность и встречи по проектам.

В одном из наших самых масштабных кейсов, реализации ИТ-трансформации в международной логистической компании, мы столкнулись с такой проблемой, о которой я расскажу ниже подробнее.

👉 Контрольные точки большинства проектов были сформулированы в терминах активности, а не конкретных результатов (например, “тестирование” вместо “завершено тестирование”) или слишком абстрактно (“изучение ИТ-ландшафта”). К тому же они распределялись неравномерно по времени: за две недели между статус-встречами могло не произойти ни одного события (контрольной точки результата) и на следующий месяц в плане также не было указано ни одного события.

Из-за этого во время статус-встреч по программе руководители не опирались на отчет, а просто своими словами рассказывали о том, что сейчас важно. И полноценной картины о том, что происходило в проектах не было, потому что:

🔹 было непонятно, какие результаты из запланированных достигнуты, а какие нет, и также непонятно, когда они будут достигнуты;

🔹 велись только прогнозные сроки, а плановые по большинству контрольных точек не фиксировались, поэтому невозможно было увидеть отклонения прогнозных и фактических сроков от плана.

Подобные ситуации всегда приводят к бесполезной трате времени на совещаниях и необходимости все перепроверять лично.

Мы проработывали эту проблему 1,5 месяца. И в итоге пришли к тому, что фокус отчетов изменился на конкретные результаты и риски, а также из статус-отчетов стало возможно получить полную картину того, что происходит в программе.

Все отклонения, их причины и последствия стали прозрачными, а содержание статус-встреч сместилось в сторону обсуждения проблемных мест проектов.

💡 Качественная, прозрачная отчетность – одна из ступенек на пути к уверенности, что проекты идут как надо, без вашего постоянного вмешательства и микроменеджмента 24/7. Что вы можете выдохнуть и начать заниматься стратегией.

Коллеги, продолжать развивать эту тему? Дайте знать реакциями и комментариями🔥