Управление проектами

Стейкхолдеры: как выжить среди политических игр Проект — это не только задачи, сроки и бюджет. Это ещё и люди. С интересами, амбициями, страхами и скрытыми повестками. И чем крупнее проект, тем сложнее политическая карта. Заказчик говорит одно, его заместитель — другое. Функциональный руководитель «поддерживает» проект, но не выделяет людей. Спонсор молчит, а потом неожиданно спрашивает: «А почему мы ещё не закончили?» И это не саботаж. Практические приёмы работы с конфликтующими интересами: Составьте карту стейкхолдеров. Не формальную, а рабочую. Кто влияет на решения? Кто блокирует? Кто выигрывает от успеха проекта? Кто проигрывает? У кого есть скрытый интерес? Выявите скрытые повестки. За красивыми словами о «стратегической важности» часто стоят личные цели: бюджет на следующий год, повышение, устранение конкурента. Понимание мотивации меняет тактику работы. Работайте с каждым отдельно. Публичные встречи — для согласования уже принятых решений. Реальные договорённости — в личных разговорах. Не пытайтесь понравиться всем. Невозможно. Ваша задача — не дружба, а достижение результата. Иногда это значит, что кто-то останется недоволен. Фиксируйте договорённости письменно. После каждого совещания — протокол: что решили, кто ответственный, к какому сроку. Это защищает от «я этого не говорил». Работа с «токсичными» заказчиками: Не принимайте на личный счёт. Токсичность часто — следствие страха, давления сверху или прошлого негативного опыта. Отделяйте эмоции от фактов. «Вы всё провалили» — это эмоция. «Срок сдвинулся на две недели» — это факт. Работайте с фактами. Устанавливайте границы. Если заказчик переходит на личности — остановите разговор. Вежливо, но твёрдо. Привлекайте спонсора. Если поведение заказчика мешает проекту — это уже не ваш уровень. Это вопрос уровня выше. Когда эскалация — это инструмент, а не слабость: - Многие PM боятся эскалации. Кажется, что жаловаться наверх — это признание собственной некомпетентности. Это ошибка. - Эскалация — это управленческий инструмент. Он нужен, когда: - Решение выходит за пределы ваших полномочий (изменение контракта, бюджета, сроков). - Конфликт между стейкхолдерами блокирует проект, и вы не можете его разрешить на своём уровне. - Поведение заказчика или участника команды создаёт риски для результата. Как эскалировать правильно: - Не «жаловаться», а «информировать и запрашивать решение». - Приходить с фактами, а не эмоциями. - Предлагать варианты, а не просто описывать проблему. - Делать это своевременно, а не когда проект уже горит. Главное: проект — это временное предприятие, а политика — постоянна. Не игнорируйте её. Не боритесь с ней в одиночку. Управляйте ею. #УправлениеПроектами #Стейкхолдеры #PMO #Политика

Почему ваш PMO никому не нужен (и как это исправить) Знакомая картина. Проектный офис создали. Прошёл год. Руководство спрашивает: «А что вы, собственно, делаете?» PMO отвечает: «Собираем отчёты».  Так рождается «мёртвый» PMO. Признаки того, что ваш PMO — бюрократическая надстройка: Вас вспоминают только в конце месяца. Когда нужно сдать отчётность. До этого — тишина. Вы собираете данные, но никто не принимает решений на их основе. Отчёты уходят «в стол». Вы мониторите проекты, но не влияете. Замечаете отклонения, но ничего не можете сделать — только зафиксировать для отчетов. Проектные менеджеры вас избегают. Потому что вы — это «ещё один слой согласований». Ваша метрика — количество отчётов, а не результат проектов. И это худший симптом. Если узнали себя хотя бы в трёх пунктах — пора что-то менять. Три сценария трансформации: Сценарий 1. «Методологический центр». PMO перестаёт только собирать отчёты и становится владельцем методологии: разрабатывает и адаптирует методики, обучает команды, консультирует и обучает PM. Фокус — на действиях, а не на контроле. Сценарий 2. «Центр компетенций и данных». PMO управляет портфелем, аналитикой и ресурсным планированием. Даёт руководству то, что ему реально нужно: сценарии «что если», прогнозы, приоритезацию. Отчётность — побочный продукт, а не цель. Сценарий 3. «Активный драйвер доставки». PMO берёт на себя ответственность за результаты, а не за процесс. Управляет зависимостями, дефицитом экспертов, эскалациями. Участвует в принятии решений, а не служит передаточным звеном между руководством и РП. Что делать, если руководство считает вас «отделом отчётности»: Перестаньте приносить только отчёты. Начните приносить решения. Вместо «проект отстаёт на 2 недели» — «вот три варианта, что делать, и моя рекомендация». Считайте не количество отчетов, а эффект. «Мы помогли перераспределить ресурсы и спасли 3 недели на критическом пути» звучит лучше, чем «мы выпустили 47 дашбордов». Выйдите из роли наблюдателя. Участвуйте в принятии решений на уровне портфеля. Приходите с предложениями, а не с констатацией. Найдите союзника наверху. PMO без поддержки спонсора обречён. Если спонсор считает вас полезными — вы выживете. Если нет — станете отделом отчётности. Автоматизируйте рутину. Если ваш PMO тратит 80% времени на сбор данных — вы не управляете, вы стенографируете. Данные должны собираться автоматически, а люди — думать. Главное: PMO нужен не для того, чтобы контролировать. Он нужен для того, чтобы помогать организации достигать целей. Если этого не происходит — вопрос не в названии. Вопрос в ценности, которую вы создаёте. #УправлениеПроектами #PMO #Трансформация

Оценка длительности: почему ваши прогнозы чаще всего оптимистичны? «Это займёт две недели».  А потом проходит месяц, и вы объясняете заказчику, почему «две недели» превратились в шесть. Почему так происходит снова и снова? Психология планирования: три причины оптимизма 1. Ошибка планирования (planning fallacy). Канеман и Тверски описали это ещё в 1970-х: люди систематически недооценивают сроки и стоимость, даже когда имеют опыт подобных задач. Мы верим, что «в этот раз всё пойдёт по плану», игнорируя статистику прошлых проектов. 2. Effect of optimism (эффект оптимизма). Мы склонны верить, что нам повезёт больше, чем другим. Пробки, болезни, сбои, «внезапные» требования — всё это случается с кем-то другим, но не с нами. В проекте это превращается в оценку «если всё пойдёт хорошо» — а «хорошо» не идёт почти никогда. 3. «Проклятие знания» (curse of knowledge). Чем лучше вы знаете задачу, тем сложнее вам представить, что что-то может пойти не так. Эксперт оценивает работу, которую делал сотню раз, и забывает про все случаи, когда она занимала в два раза дольше. Новичок, наоборот, боится всего и часто даёт более реалистичные оценки. Что делать: практические приёмы 1. Оценка по трем точкам. Вместо одной цифры — три: оптимистичная (O), ожидаемая (M), пессимистичная (P). Расчетная длительность считается по формуле PERT: E = (O + 4M + P) / 6 Это способ учесть неопределённость. Если разброс между O и P огромный — это сигнал: задача плохо понята, нужно декомпозировать. 2. Буферы. Не прячьте резервы внутри задач. Выносите их отдельно. Буфер — это не «увеличение сроков», это страховка. Если буфер не понадобился — вы сдали проект раньше. Если понадобился — вы не нужно объяснять заказчику, почему «две недели» превратились в шесть. 3. Метод Монте-Карло. Полноценное моделирование требует специальных инструментов. Как работает Монте-Карло: - Для задач с большой неопределенностью в плане задайте три оценки (O, M, P). - Внесите риски в план проекта. Оцените их вероятности. - Для каждого риска разработайте последствия – «что произойдет с проектом если риск наступит». И внесите их в план. - Запустите генерацию сценариев: для каждой задачи случайно выбирается длительность в диапазоне O–P с учётом распределения. Риски при каждом сценарии также «происходят» с учетом их вероятностей.   - Рассчитывается длительности проекта для каждого сценария. - Получите распределение: вероятность завершить проект к определённой дате. - Примите решение о том, какая вероятность завершения проекта допустим для вас и заказчика. - Аналогично можно сделать моделирование затрат. Если нет Spider, то метод Монте-Карло возможно сделать с помощью VBA в MS-Project. Excel оставьте в покое – он не для этого. Освоить VBA для MS-Project можно на моих курсах. 4. Оценка по аналогам с поправкой. Возьмите похожий проект из прошлого. Посмотрите, сколько он занял фактически, а не по плану. Добавьте поправку на различия. Это самый честный способ — он основан на реальности, а не на вере в лучшее. 5. Декомпозиция. Чем крупнее задача, тем выше неопределённость. Разбейте работу на мелкие шаги — так вы увидите, где именно скрываются риски, и сможете оценить каждый шаг отдельно. Как перестать обещать «через две недели» Не давайте оценку сразу. «Я вернусь с цифрой завтра» — это профессионально. «Две недели» на встрече — это гадание. Говорите диапазоном. «От двух до четырёх недель, скорее всего — три» — честнее, чем «две недели». Показывайте неопределённость. Если вы используете оценку по трем точкам, покажите заказчику разброс. Это не слабость, это управление ожиданиями. И да, в договоре лучше ни использовать оптимистичную оценку. Отслеживайте ход проекта. Сравнивайте план с фактом. Если ваши оценки систематически занижены на 30% — вносите поправку. Это называется «калибровка». Главное: реалистичные прогнозы — это не пессимизм, а профессионализм. #УправлениеПроектами #ОценкаДлительности #PERT #МонтеКарло #VBA