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