Всем привет! Этой статьёй я открываю серию постов из моего личного опыта, которого у меня больше 25 лет, из которых 20 — в управлении проектами. Я заметил, что в моей ежедневной работе, работе моих менеджеров, постоянно происходят ситуации, которым очень мало обучают на тренингах, но которые в жизни любого РП случаются регулярно. И я начал их записывать.
Что делать, если сроки срываются, а вы не виноваты? Что делать, если заказчик требует невозможного, а сказать «нет» нельзя? Что делать, если вы чувствуете, что вы везде крайний, а никаких инструментов повлиять на ситуацию у вас нет? Ничего этого нет в PMBoK или Agile Manifest. Как сделать действительно качественный продукт, как принести прибыль компании, а себе заработать денег, вас не научат на курсах владения MS Project. Но вам может помочь опыт других РП, которые уже прошли то все сами и понимают, почем фунт лиха.
Так что надо делиться.
Ну и терапевтический эффект тоже важен: как известно, со своими проблемами лучше не оставаться наедине, думая, что именно ты какой‑то не такой, ужасный неудачник, а кругом одни удачники. Это не так, лажают все, просто рассказывают не все (особенно в сети).
Я расскажу.
Итак, с чего начнем? Начнем с базы.
Что такое «Успешный проект» или как стать Успешным Менеджером который умеет делать Успешные проекты?
Для тех, у кого нет времени, и лень читать лонгрид, сейчас будет тизер: никак. Вы не сможете понравиться всем, особенно на горизонте 10–15 лет, так что придется просто много и качественно работать.
Кому интересны детали, идем дальше.
Как‑то я сделал почти одновременно 2 проекта. Первый проект был сделан с превышением бюджета на 2 или 3 тысячи человеко‑дней (да, да — тысячи человеко‑дней, я не ошибся). При контрактной длительности в полгода работы длились полтора года. На проекте было множество эскалаций до уровня Вице‑президентов и даже CEO. Закончился этот проект убытками и небольшим пресс релизом об успешном внедрении. Но затем система начала развиваться и, спустя 5 лет, уже приносила прибыль заказчику и вендору. А, спустя еще несколько лет, на основе этого успешного внедрения, вендор сделал еще одну продажу (а одна продажа там исчислялась миллионами долларов).
Второй проект был выполнен строго в заявленные сроки. Даже быстрее. Проект принес прибыль компании. ПО было успешно передано заказчику. Однако, заказчик обнаружил, что его сотрудники так и не смогли начать пользоваться системой, она была слишком сложной. Заказчик запросил доработки и дополнительное обучение, на что ему ответили, что все работы были выполнены строго в соответствии с ТЗ, он сам все принял и подписал, так что никаких дополнительных работ проведено не будет. При этом, прибыль от проекта позволяла выделить время и для небольших доработок, и для обучения, но решение было принято именно такое.
В итоге отношения на аккаунте были испорчены и продолжения работы не получили.
Какой из проектов был успешным?
Для меня вопрос «что такое успешный проект?» — это вопрос, не имеющий однозначного ответа. Такие вопросы хорошо спрашивать на собеседованиях, там видно, во‑первых, опыт кандидата, а, во‑вторых, если кандидат достаточно сильный и уверенный в своем опыте, далее следует интересный разговор.
Начинающие руководители проектов обычно отвечают: это проект, который принес пользу заказчику. Реже говорят, что успешный — это когда принес прибыль компании.
Менеджеры поопытнее отвечают, что успешный проект — это который и принес пользу, и принес прибыль.
А вот менеджеры с большим опытом откидываются в кресле назад, задумчиво смотрят вдаль, загадочно улыбаются, а когда отвечают, говорят много, долго и интересно.
Потому что недостаточно, чтобы была прибыль. Надо еще и сохранить хорошие отношения для новых работ. Надо еще позаботиться о команде, чтобы она не выгорела и не разбежалась. А еще внутри проекта может быть сложная конфигурация участников как со стороны тех, кто заказывает работы и тех, кто их делает.
Одно время я сам любил отвечать на этот вопрос так: «успешный проект, это проект, который считает успешным мой руководитель». Сейчас я вижу, что и у руководителей разного уровня в одной компании могут быть разные цели (тут сложная материя про стратегические и тактические цели, OKR и так далее. Погружаться сейчас не буду, просто зафиксирую, что так бывает). К примеру, у CEO задача делать хороший сервис, чтобы аудитория была лояльной, а у менеджеров среднего звена стоят конкретные планы по внедрению фич для этой самой лояльности. И менеджеры получают премию за факт внедрения и им (бывает так) плевать на качество, главное — просто сдать. И вот тут вы, как Руководитель проекта встаете перед классическим выбором: делать быстро и некачественно, зато порадовать вашего прямого заказчика или делать долго и качественно, вызвать гнев прямого заказчика лишить его, возможно, премии, зато долгосрочно сделать качественный продукт, удовлетворив долгосрочным целям компании. Как тут быть и что мне, как исполнителю, считать успехом проекта?
Как сейчас отвечу я на этот вопрос: есть формальные критерии успешности проекта, есть неформальные. Успешный проект должен соответствовать им всем. Но всем критериям, особенно изменяющимся во времени, вы соответствовать не сможете никак.
Что такое счастье, каждый понимает по‑своему. Более того, в каждый момент времени это понимание меняется.
Именно поэтому менеджеры, которые сделали много проектов, загадочно улыбаются. «Успешный проект» — это как сферический конь в вакууме. Гнаться за ним не имеет смысла, а все, что может и должен сделать РП, это постараться максимально четко зафиксировать критерии приемки и постоянно доносить их до всех участников проекта. Это и есть, во многом, смысл существования РП: чтобы все в команде, от спонсора, который за все это платит, до тестировщика, понимали цели более‑менее одинаково.
Тогда, даже если во времени проект будет не очень успешным, вас запомнят, как четкого и толкового исполнителя. Да, карта не легла, но вы рубились честно и качественно.
А если случится так, что и пользу принесли, и прибыль компании, и все довольны, тогда будет вам и слава, и бонусы, и почет с повышениями (хотя это все равно не точно ?). Сможете записать историю успеха у себя в резюме ?
Комментарии (15)
b00b1ik
05.08.2024 15:41+1хорошо раскрыто, но ведь это понимаешь после пары проектов (то есть через 1-2 года) РПшства.
а если не понял, то там же грусть печалька и строго по треугольнику и пмбок тебе путь.
peterzh Автор
05.08.2024 15:41я собеседовал , наверное, менеджеров 30 за последнее время. И опыт был не 1-2 года, а прямо 4 даже (заявленных). Очень мало кто отвечает про то что "успешный проект" - это такой сферический конь в вакууме и показатели если не только бюджет/скоуп/деньги. Потому и захотелось высказаться на тему
b00b1ik
05.08.2024 15:41а еще они про манипуляцию не скажут))
просто это не РП, как говорил мой аналитик, они просто не в профессии. кто в РП идут? те кому не хватило ума быть разрабом, кого не взяли даже в тестировщики, изредка аналитики. но все это не менеджеры же.
я же сказал, РП поймет за 1-2 проекта, а остальные просто не менеджеры и никакие статьи им не помогут.
wolodik
05.08.2024 15:41На вопрос что такое успешный проект всегда хочется уточнить - "а для кого успешный"? Статья кратко намекает, что фактические критерии успешности не всегда совпадают с их формальным определением, но самое-то интересное - и что дальше, что с этим делать?
peterzh Автор
05.08.2024 15:41Вот именно эту тему я и буду раскрывать в бложике, по мере сил. Понимаю, что вопрос глубоко философский и опираться я могу только на личный опыт, но зато его много, да и обсудить будет что :)
1972den
05.08.2024 15:41+1Очень интересная статья и в основном согласен с поднятой темой. Сам я сталкиваюсь с аналогичными вопросами в своей работе и практические примеры такой «биполярочки» и видел, и участвовал. В своей практике придерживаюсь следующей тактики: стремиться сделать проект в рамках бюджета-сроков-содержания, а выстрелит потом результат проекта или нет - это вопрос не к РП, а к заказчику. Здесь у каждого своё представление об успешности проекта)
Batalmv
Мне кажется, надо строго разделять ответственность
"продакт" отвечает за то, какой бизнес эффект принесет
"аккаунт" отвечает за взаимоотношения с клиентом
"спонсор" за бюджет и готовность его тратить
ПМ делает свою работу в первую очередь. Радоваться тому, что сделал проект, вылетев в стратосферу по бюджету - не вижу ничего хорошего. Да, потом проблему зарешали, причины пояснили - но для ПМ это не проект, а катастрофа. Как минимму тут нечего откидываться и предаватья долгим рассуждениям. Разве что стоит подумать, почему был допущен такой "факап"
Потому ответ, как ни странно просто. Есть бюджет, сроки, скоуп. Сделали в рамках - молодец. Не сделали - вопрос, почему? Можно ли было лучше. Все остальное, особенно выше - ответственность других людей, который закрыли ПМа неумеху своими действиями
peterzh Автор
Вы знаете. Суть моей статьи как раз в том, что есть две крайности
Я работаю строго по должностной и отстаньте от меня со своими дополнительными задачами.
Я спасаю мир, я делаю вообще все: и то, что мне поручили, и то, что не поручали я делаю тоже
Первый подход превращает команду в формалистов. Я видел людей, которые так работают. Как Руководители проектов - они не эффективны, у них плохие отношения с заказчиками (без исключения, в моем опыте).
Второй подход очень нравится руководству, но ведет к выгоранию или к увольнению - это когда герой не справляется.
По моему опыту очень большого числа внедрений, нужно искать баланс. Где надо - уметь подстраховать и подумать чуть больше, чем это предусмотрено должностной инструкцией или ТЗ. Но уметь и сказать "нет" заказчику или руководителю.
Как найти этот баланс, опять таки, по моему опыту, не знает ни один РП, который приходит в профессию. Все набивают свои шишки.
Batalmv
Я не знаю, где есть две крайности :) В реальном мире все есть оттенки. Рецепт же прост
в первую очередь вы делаете свою работу
потом можете помочь другим
Потому что закон джунглей прост. Каждый сначала есть свое "дерьмо". В случае ПМ. которые по большому счету несет ответственность за результат проекта - он есть за всех, кроме случая, когда это "большой талант" находить козлов отпущения.
Причем тут формальности - я вообще не понял. Понятно организации бывают разные, но в большинстве случаев роль "аккаунта" есть почти везде. И это его функция - отношения с клиентом. С какой стати ПМ, который допустим перерасход на космическую сумму лезет туда - лично мне неясно.
Причем тут выгорание - также не ясно. Любое "спасение мира" - это следствие чьей-то глупости и некомпетености :) Вопрос - а как так-то
-------------
Главное, что я точно перестал понимать - почему у вас кроме крайностей, больше ничего нет. И зачем вообще искать баланс там, где можно просто работать?
Да, все делают ошибки. Но ... честно говоря,
Знаете, понятно - нельзя быть всегда успешным. Но это не спорт, где какие-то команды 100 лет не могут ничего выиграть. Это обычный бизнес, где успех скорее норма, чем исключение.
И честно говоря, человек. который "рубиться" - пусть идет в дроосеки, а не его место придет тот, кто будет делать результат :)
peterzh Автор
В статье есть две крайности, просто чтобы дать понять, как оно в жизни бывает. Оно бывает по-разному. Уверен, если бы мы тогда замерили то, что я научился замерять сейчас (удовлетворенность клиента и удовлетворенность команды), результаты были бы крайне интересные и подтверждающие мои тезисы.
А вот то, что вы написали про успешность в конце камента, и есть посыл моей статьи. Менеджеры проектов часто боятся показать неуспешными, я сам таким был. Линкед ин пестрит успешным успехом. Но так бывает не всегда. И не надо за этим гнаться. Надо честно делать свою работу. А уже рубиться или нет - каждый сам пусть выбирает.
Я иногда люблю и порубиться.
Batalmv
Ну смотрите. Все ж просто. Я условно ПМ. Я работал в этой роли, если что.
У меня есть:
спонсор проекта, к примеру внешний VP
есть мой аккаунт, который отвечает за клиента в целом
есть владельцы ресурсов / спонсор в моей стороны, который являются прямыми выгодополучательми
Дальше ж все просто. Есть бюджет, сроки, скоуп. Повторяюсь. Они есть в контракте в том или ином виде. В fixed явно, в вариантах dedicated team / почасовка не так явно.
Мои задачи, помимо project execution:
выйти на ожидаемый результат моего спонсора, который хочет заработать
давать и получать фидбек аккаунту, чтобы корректировать тактику и стратегию
Дальше возможны варианты, в том числе и описанные у вас. К примеру, мой спонсор решил "прогнуться"сейчас, чтобы заработать потом, так как видит возможность заработать стратегически. Ну ОК. Но я обязан как ПМ получить новый бюджет, так как аукцион невиданной щедрости должен иметь границы, так как владельцы ресурсов все равно выставят счет. Но тогда это не "факап", а осознанный ChR. Главное чтобы он был заранее, а не по факту.
Но всегда важно понимать, то все эти люди и какие о них интересы. Тогда проект будет успешным. А статья о том, что есть "два крайних кейса" ... да нет их. Точнее из не два, а много. Так как у спонсора со стороны клинета свой интерес, у моего - свой, у владельцев ресурсов - третий. А часто еще есть мой непосредственнй начальник.
Но здесь опять же нет никакой магии. Вы должны знать эти интресы и двигать проект в этом направлении. И делать что-то когда совместное достидение целей в приницпе невозможно
Тогда станет понятно, как конструктивно оценить "успешность". А вашем случае ... ну извините за прямоту, но все это вы упустили, просто предавшись уютным воспоминаям о том, что жизнь страння штука
Хотя как раз все это прозрачно и очевидно структурируется и определяется. Но возможно не для всех :)
zamorinvi
Уж лучше радоваться проекту, сократив объём работ, но попасть в бюджет. Потом получить претензию и всё бесплатно дорабатывать, но уже не в позиции win-win. Класс.
Расписать "книжную" теорию и не знать, что ролевые модели могут быть совсем другие, с большим количеством совмещений в силу тех или иных обстоятельств (количества сотрудников, например).
Суть этой статьи, на мой взгляд, - мыслить шире, не ограничивать себя книжной теорией и идти к результату совместно со всеми заинтересованными лицами.
Batalmv
Выше было написано
Вы можете играться, заменяя "факап" по бюджету на "факап" по скоупу, но сути это не меняет. В реальности ПМ такого проекта эпично облажался (хотя неодолимые внешние факторы могут иметь место быть), но его провал был прикрыт вышестоящими товарищами
Конечно, в мелких конторах часто функцию "аккаунта" выполняет ТОП организации или даже владелец, иногда сейл. Иногда и ПМ. Но тогда в данном случае все что вы пишете не сильно актуально, так как большинство ПМов эту функцию не выполняет
Либо стоит писать в заголовке "Как завалить проект, но перетереть с клиентом и спасти ситуацию"
Вы не можете этого делать, если вы в организации "заперты" своими функциями. И смотреть шире вы можете, только если допустимо совмещение, что я и пытаюсь донести.
peterzh Автор
В данной выше ситуации РП облажался ровно один раз, когда вначале принял проект (вместо полностью уволенной команды) и попытался сходу сдать этап, не оценив масштаба бедствия и не предупредив о невыполнимости показателей. Но он тогда был еще молодой и зеленый, так что простительно.
В дальнейшем, решение о продолжении работ принималось и его руководителем, CTO и CEO компании. Там был хороший уровень эскалаций. Более того, решение продолжать или нет, принимались каждые 1-2 месяца, исходя из общения с заказчиком.
С учетом этого интересно, где РП облажался еще?
Batalmv
Может и нигде :)
Просто вы же видете, все как я и написал в первом коменте. Старшие дяди аккуратно разрулили проект и вырулили "в плюс"
Но тогда вы просто это неверно подали. Фактически нарушения бюджета НЕ БЫЛО, так как внутренний спонсор дал добро на его увеличение
Тут важно описывать ситуацию корректно
--------------
Но важен также момент, что ПМ обязан вписаться в новый бюджет. Не он решает, сколько можно потратить сверху. И не он это считает
В больших и очень больших конторах все это считается вообще очень далеко от ПМа или даже от кантри лидера. Но потом, когда оно подсчитано - ПМ обязан вложиться в результат
Поэтому давайте не подменять ситуацию "успешного" проекта с перерасходом бюджета ситуацией когда в проект сначала ВЫДЕЛЕЛИ доп. бюджет. А вы зачем-то об этом умолчали, хотя было достаточно очевидно, что это имело место быть
И нет никакой философии здесь или друнгих критериев успеха. Вы всегда должны попасть в рамки, заданные спонсорами.