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

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

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

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

Руководители департаментов увидели проблемы и договорились решить её совместно. Так появился проект. Определили фокус группу, объяснили в чём выгода каждого лично и компании в частности и начали проект.

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

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

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

- Ой, а почему кнопка не зелёная! Я просил зелёную. Ну вы не записали тогда, сейчас запишите. Когда исправите ошибку - я продолжу проверять.

Человек вставал и уходил. Следующий раз, когда, когда он доступен - через неделю.

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

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

При это руководители департамента требовали у руководителя проекта вернуться в сроки и запустить проект как можно быстрее, ибо мы теряем много денег!

Когда руководитель проекта описал директору департамента А, что и как происходит, то он позвонил одному из сотрудников и у них состоялся диалог:

- Как у вас двигается проект?
- Всё хорошо!
- Когда будет результат?
- Надо спрашивать у руководителя проекта. Мы всегда приходим на встречи, но там постоянно что то не работает! Мы так хотим уже работать по новому, но уже устали от постоянных проблем этих..

И руководитель проекта оказался не в очень приятном свете - проблема то оказывается в том, кто реализует проект!

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

В финале пришла информация об инициации нового проекта и потенциальном участии разработчиков и текущего проекта в нём. Это означало что через какое то время проект практически без ресурсов.

С этой историей ко мне пришёл руководитель проекта и попросил помочь:

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

- Паша, закрыть проект много ума не надо и делается это всё просто идёшь к спонсору и просишь тебя убрать с этой роли (читай уволить). Но прежде скажи - ты веришь в результат проекта, в то что он полезен компании?
- Конечно верю! После запуска и людей меньше будет в отделе, не будет мест для махинаций, да и количество замороженных денег на складе сократиться так, что мы сможем ещё 10 таких проектов сделать!
- Вот тебе и ответ! Даже если люди не занимаются махинациями, они боятся что их уволят после запуска проекта. Они даже могут этого не осознавать, но всячески оттягивать запуск проекта.
- Так и махинациями они занимаются!
- Если у тебя нет доказательств, не используй это. Ты будешь вруном в этом случае. Да и опираться на то, что они возможно боятся увольнения тоже нельзя. Ты руководитель проекта и оперировать фактами. Интуиция нужна что бы понимать где искать эти факты. Поэтому мы сделаем вот что...

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

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

А план и реализация была следующей.

1. Принять проект у самих себя. Протестировать всё самостоятельно. Знание о процессе и возможных варианта команда уже знала хорошо. Поэтому она была способна проверить всё, как минимум на 95%! Во время этого теста были найдены несколько критических ошибок и они были исправлены.

2. Определить правила тестирования и определения что делать с ошибками и новыми запросами. Все делить на три категории:

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

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

3. Договориться с руководителями департаментов о выполнении правил из пункта 2 выше и о трех встречах:

  • Первая встреча - когда соберутся и руководители департаментов обозначат эти правила и распорядятся выделить время на тестирование. На этой встрече у каждого лично спросили "Вы согласны исполнять эти правила?" и получили ответ голосом.
  • Вторая встреча - первый день тестирования. Смысл участия руководителей - они должны увидеть как работают их люди и возвращать их в конструктивное русло. По итогу встречи они должны передать это право руководителю проекта (или дальше приходить на эти встречи). В нашем случае те, кто цеплялся за цвет кнопок и "тся\ться" не выдержали и раскрылись во всей красе перед руководителям. Они были возвращены в конструктивное русло и в конце дня они сказали "Павел, если подобное будет происходит в следующие дни - набирайте сразу нас, мы подойдём и поможем"
  • Третья встреча - когда подводят итоги и принимается решение о начале пилотирования и подготовке к масштабированию. На встречу выступали уже сами бизнес-пользователи. Самой горячей темой были ошибки\задачи, которые можно сделать уже после проекта, но было бы очень полезно сделать до начала масштабирования.

4. Провести все плановые тестирования. Тут случилось чудо - люди, которым раньше было некогда, начали тестировать сверхурочно. Это позволило сократить срок тестирования почти в два раза!

В результате через 1.5 недели было принято решение о начале опытно промышленной эксплуатации. Ещё через 2 недели приняли решение о начале масштабирования.

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