Проектная страшилка: почему проекты умирают
Привет, меня зовут Виолетта, я IT BP и руководитель программ проектов, работаю более 20 лет в IT, из них 13 – в проектном управлении.
Часто вижу холивары на тему того, как не сорвать проект, сделать все в срок, в бюджет и именно то, что хотел заказчик. Волшебной таблетки тут не существует, все зависит от среды, ситуации и навыков руководителя проекта.
Но, по моему опыту, есть не совсем очевидные, но сильно влияющие на достижение успеха вещи, которыми могут пренебрегать. И их несоблюдение ведет к «смерти» проекта и к печальным последствиям как для руководителя проекта, так и для результата в целом. И тут совершенно неважно, какую методологию управления проектом вы используете.
Моей подруге как-то довелось попасть на операцию и при подготовке к ней, медсестра командным голосом сообщала важную информацию:
Если вы поедите утром – вы умрете.
Если вы не наденете компрессионное белье – вы умрете.
Если вы не будете пить назначенные лекарства – вы умрете.
Как и в жизни, в проектах есть некоторые вещи, нарушение которых с высокой вероятностью приведет к проблемам в проекте, а некоторые последствия могут быть фатальными.
Мои рекомендации ниже – это техника безопасности по управлению проектом. Они написаны «кровью» проектов, которые закончились плохо, и основаны на моем опыте, опыте моих коллег и сотрудников.
Рекомендации основаны на трех вопросах к РП и правилах к ним:
Есть план-график проекта и как с ним работают?
Как фиксируются договоренности и изменения ключевых параметров проекта?
Есть понимание процессов в компании?
Вопрос №1: Есть план график проекта и как с ним работают?
План-график – один из основных инструментов управления, планирования и прогнозирования при реализации проекта. Все задачи, взаимосвязи, зависимости ложатся в него и из этого рождается реальный срок проекта.
Чем обычно пренебрегают:
не ведут план-график вообще или ведут его формально
не работают с ним каждый день
не обсуждают его с командой и заказчиком
Что делать, ��тобы получить максимальную пользу от него:
Правило безопасности №1: обязательно вести план-график и обсуждать его с командой и заказчиком регулярно
План-график – живая карта достижения целей проекта, как вы с командой принесете результат ко сроку, какие у кого задачи и сколько времени они занимают. Это тот артефакт, который сможет помочь сплотить команду и сфокусироваться на целях и результатах.
Вовлекайте всех в обсуждение и рассмотрение, передавайте ответственность команде выполнить задачи в срок, ведь за ними еще стоят другие люди и другие задачи. Вводите элементы игры и драйва, чтобы достигнуть цели в срок. А с заказчиком обсуждайте, что стоит на вашем пути, чтобы он получил результат, рассказывайте сколько работы он не видит и сколько это занимает времени, чтобы снять вопросы «почему так долго».
Правило безопасности №2: обсуждайте ваш план-график с другими РП и своим руководителем.
«На своих ошибках учатся, а на чужих делают карьеру» – используйте чужой опыт для реализации проекта. Наверняка рядом с вами есть проект в более зрелой стадии, спросите его РП с чем он столкнулся за ближайшие месяцы и как он это решил. Не надо из себя строить одинокого воина, который должен пройти свой путь, – спросите своего руководителя, откуда его «шрамы» и как он выжил, покажите ваш план и соберите его опыт. Так вы сможете избежать очевидных ошибок.
«Грабли» по этой теме:
РП рассказывает, что все важные задачи у него в голове. Прошу собрать их в план и рассказать, что и как он делает. В итоге был потерян этап подготовки к переводу критичных интеграций на живой системе. Ему казалось, что не надо ни с кем договариваться и это ни на что не повлияет.
При планировании не учли важный этап, который ввели недавно в компании, и это добавило 2 месяца к проекту. А достаточно было просто попросить РП из соседней ветки глянуть план-график и он бы рассказал с чем столкнулся.
Заказчику не показывали план-график, в результате, когда хотели провести старт опытной эксплуатации, выяснилось, что в это время будет технический ремонт физического объекта инфраструктуры и проверить работу не получится.
РП не включил релизный график в свой план, и узнали только когда показали план-график сервисной команде. В итоге сдвинулись на 2 недели.
Вопрос №2: как фиксируются договоренности и изменения ключевых параметров проекта?
Правило безопасности №3: фиксируйте все изменения ключевых параметров проекта и договоренности.
Все, что не зафиксировано и не согласовано всеми участниками –просто разговоры. Вы сколько угодно можете рассказывать, что вы договорились и решили все на встрече, люди могут ответить «не помню» и вам будет нечего предъявить. И в этом случае плохим все равно будет РП. Но не надо забывать, что РП выделяют деньги на реализацию конкретной задачи и он не вправе единолично менять ключевые параметры проекта –такую ответственность на себя берет заказчик.
Рекомендую следующую иерархию фиксации договоренностей:
изменение ключевых параметров проекта: сроки, задачи, бюджет, а также кросс-командные договоренности и ключевые решения – протокол за подписью заказчика, РП и других членов команды, которые вправе это утверждать.
обещания кого-то вам что-то сделать – достаточно записи «мемо» по итогам встречи или дублирующее письмо в почту «По итогам обсуждения по телефону, фиксирую договоренности».
внутренние командные договоренности – фиксировать на статусах в задачу или в план-график, желательно прилюдно.
«Грабли» по этой теме:
не зафиксировали, что заказчик заменил фичу – в итоге на демо он сказал, что все не так и вообще такого не говорил
соседняя команда обещала выкатить обновление платформы в срок, в день Х платформа не выкатилась – договоренности не зафиксировали, даже не провести корректно эскалацию.
Вопрос №3: есть понимание процессов в компании?
Правило безопасности №4: изучите процессы в вашей компании при реализации проектов.
Вам крайне важно понимать, как работают процессы в компании при реализации проекта: Как запросить ресурс? Как заключить договор? Кто согласовывает релиз? Как согласовываются артефакты проекта? Критически важно понимать как организован процесс по шагам, кто за него отвечает и сколько это времени занимает. Это напрямую влияет на сроки реализации проекта. А самое важное – зная нужных людей и познакомившись с ними лично, при большой потребности можно «срезать углы» или попросить помощи что-то сделать быстрее, чем по регламенту. Идите к таким людям очно, если это возможно, приглашайте на обед или занесите шоколадку, такие друзья вам будут очень нужны.
Правило безопасности №5: необходимо знать политическую обстановку в компании.
Как бы вы не хотели погружаться в политическую обстановку, она на вас влияет регулярно, поэтому очень важно ее понимать. Понимая мотивы и цели людей, а особенно если это стейкхолдеры, заказчики, руководители, вы сможете понять, как управлять их ожиданиями, что стоит делать, а что нет. Как узнать политическую обстановку? Поговорите с руководителем, поговорите с коллегами и теми, с кем вы в хороших отношениях.
Что уточнять:
как давно человек в компании;
где он работал ранее и как двигался по иерархии внутри;
за что он отвечает, какие его задачи и цели;
что он за человек и какая у него репутация;
какие есть особенности при работе;
как лучше выстраивать с ним коммуникацию;
с кем он конфликтует и с кем он дружит;
какие хобби и чем увлекается.
Это поможет понимать реальные цели и задачи проекта, распознавать на ранних стадиях, где будет сопротивление при внедрении, или подумать, как подружить заклятых врагов, чтобы ваш проект не стал разменной монетой в их конфликте.
«Грабли» по этой теме:
Послали новичка тендер заключать. Не разобравшись в процессе, он отрапортовал, что за 3 недели все сделает. А по факту там нужно подавать все в план закупок за 3 месяца, заполнить 10 документов, на рынок сходить, оценок запросить и не только. Сорвал бедолага сроки не разобравшись.
Классика: если вы в хороших отношениях с релизной и сервисной командой, то для вас и релиз во внеурочное время выкатят. А если надо документ какой согласовать, то и звонок своему человеку может с двух недель до двух дней сократить согласование.
Играл РП в хоккей компанейский вместе со своим заказчиком в одной команде, наладил отношения и принимались результаты быстро и без загвоздок.
Запустили большой и дорогой проект. В процессе выяснилось, что заказчик в контрах с руководителем бизнес-юнита, на который накатывали автоматизацию — еще с прошлого места работы. Пришлось руководителю проекта работать переговорщиком, пояснять требования от одного к другому, рассказывать пользу — так аккуратно и внедрились.
Запустили небольшой проект, а он не идет. Требования не собрать, заказчик «вялый». Оказалось, ему задачу дал шеф, а сам заказчик уже сидит с оффером — и рассказать никому не может, и проект не бросить, и требования писать страшно.
Хуже, конечно, когда топ-менеджмент начинает соревноваться, кто круче. Об этом лучше узнать сразу и работать уже на опережение конкурирующей стороны, а не просто делать проект.
Резюмируя, работа РП – как жонглирование ножом, бомбой, кроликом и бог знает чем еще, балансируя над пропастью. И наша задача – контролировать все что в наших силах, и, по моему опыту, описанные выше правила могут добавить спокойствия и сохранить нервные клетки.
Поделитесь в комментариях, какие правила вам откликнулись и как вы сами столкнулись с проблемами при их несоблюдении. А может есть, что еще добавить, по вашему опыту, в список правил?
