Век живи - век учись...

21 июль, 2011 - 16:37Владлен Березин

Наконец появилось время написать на КО первый из серии очерк о проекте внедрения MS Dynamics DAX на Киевском Картоно-Бумажном Комбинате. Данный проект интересен с точки зрения, как технологии управления, так и самой сути внедряемых бизнес процессов. О самом проекте, его нюансах, истории и "выученных уроках" - в следующем посте.

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

Итак, в литературе, в принципе рассматривается 3 варианта взаимоотношений РП - Заказчик проекта:

1) РП - "внутренний ресурс" Заказчика, т.е. входит в штат предприятия и назначается в качестве РП, как правило, руководитель одного из линейных подразделений Заказчика

2) РП - "внешний ресурс" по отношению к Заказчику, но входит в штат компании, "внедряющией" проект, т.е. одного подрядчика, либо главного подрядчика, у которого может быть энное число субподрядчиков

3) РП - "внешний ресурс" по отношению к Заказчику, но он либо частное лицо (фрилансер), либо входит в штат компании, продающей именно услуги по управлению проектами

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

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

Очевидно, что каждая схема имеет свои достоинства и недостатки. И при выборе того, какой вариант выбрать, необходимо учитывать эти нюансы, что есть работа Заказчика и Спонсора проекта, в частности.

Итак вариант 1

Достоинства: а) РП знает специфику предприятия, на котором работает, включая процессы, формальные и не формальные отношения, людей, структуру и т.д.

б) РП лоялен именно к данному предприятию и будет всячески отстаивать его интересы в случае проблем и неизбежных конфликтов

в) низкая стоимость работ РП для предприятия

Недостатки: а) как правило, такие РП не являются профессионалами именно в управлении проектами вообще, и такими типами проектов в частности. Исключения в данном случае возможны при наличии развернутого и "продвинутого" Проектного офиса, что в нашей стране лично мне ни разу не попадалось.

б) "замыленный" взгляд на процессы, процедуры и отношения, который может быть серьезным препятствием для выполнения своей новой роли

в) как правило, отсутствие методологии, включающей процедуры, документацию и т.д. для внедрения такого типа проекта (я, в основном, имею в виду ERP проекты)

г) РП выполняет, как правило, свою операционную работу на предприятии, от которой его никто не освобождал

Вариант 2

Достоинства: а) РП специализируется именно на таком типе проектов

б) подрядчик предоставляет методологию и, как правило, свою систему управления проектом, включая специализированное ПО

в) РП является внешним для предприятия ресурсом и, соответственно, обладает "свежим взглядом" на процессы и процедуры

Недостатки: а) РП не обладает знаниями процессов Заказчика

б) РП лоялен к подрядчику и, в реальности, будет отстаивать именно его интересы

в) Стоимость работ РП велика

Вариант 3

Достоинства: а) РП специализируется на этом типе проектов и является именно РП, а не начальником, например, отдела продаж

б) РП имеет "свежий" взгляд на процессы и процедуры Заказчика

в) РП заинтересован в успехе проекта, ибо от этого зависит его моральное и материальное вознаграждение

Недостатки:

а) РП не знает (речь идет о начальном этапе проекта) процедуры, процессы, отношения внутри компании Заказчика

б) РП не имеет формальной власти в организационной структуре Заказчика

в) РП не отвечает за проект финансово

Отдельно о стоимости и лояльности РП по третьему варианту: стоимость его (именно работ, связанных с управлением проектом) выше, чем в варианте 1, но ниже, чем в варианте 2. Лояльность к Заказчику тоже значительно выше, чем в варианте 2, но ниже, чем в варианте 1.

В реальности в третьем варианте РП выступает в основном в качестве управляющего элемента и в формальных отношениях работает через Спонсора. В неформальных отношениях полностью стирается разница между сотрудниками подрядчика (подрядчиков) и Заказчика, т.к. целью является успешное завершение проекта. Также значительно повышается "свобода маневра" в принятии решений по привлечению либо удалению подрядчиков, отдельных сотрудников, принятию корректирующих мер при негативных тенденциях.

Можно так же сказать, что в третьем варианте значительно повышаются требования к качествам РП, связанными с неформальной властью, умением общаться, управлять людьми, решать конфликты и т.д. Понятно, что идеала в этих "soft skills" достичь невозможно.

Если говорить о проекте ККБК, то он начинался со схемы 2, т.е. на момент начала проекта и на некоторый период предполагался один подрядчик (Innoware), его методология, его РП, его система управления проектами. Однако, примерно посередине проекта Спонсором было принято решение о переходе к третьему варианту. Причины данного решения связаны с реализацией проекта, проявившимися проблемами и т.д. Об этом нужно говорить детально в привязке ко времени и системе. Это я планирую описать позже, т.е. после выхода релиза о запуске проекта в эксплуатацию.