За мою карьеру в сфере автоматизации, в разных проектах я была в разных ролях и даже по разные «стороны баррикад», т.е. и в роли ответственного со стороны Заказчика, и руководителя проекта, и аналитика Исполнителя.
Руководитель проекта
Недавно на встрече Клуба руководителей IT проектов я слушала доклад РП одного наукоемкого предприятия, который честно заявлял, что даже для экспресс-оценки стоимости проектов у него не хватает компетенции в отраслевой специфике своего предприятия. На возмущенные возгласы зала РП ответил, что для него позиция руководителя проектов (РП) — это скорее позиция управленца, а не эксперта, что для эффективного управления проектом нужно скорее школа ABM, а потом уже отраслевые навыки, которые как-нибудь приложатся.
Работала я на позиции аналитика и с РП, придерживающимися этого мнения, и с экспертами в своей области без управленческих навыков, и с РП, которые и управлять не умели и продукта своего не знали, а только умели качественно продавать… И с первыми, и со вторыми, и с третьими проект не выигрывал.
Если по функциям у РП есть провал, то это значит, что…
— Либо аналитик (эксперт) берет на себя какую-то функцию, не исполняемую РП. Причем, это обычно происходит с большим опозданием и возможным конфликтом, типа: «Не говори мне, что я должен делать, и не узнаешь…»
— Либо проваленную административную функцию берет на себя ответственный со стороны Заказчика.
— Либо проект заранее обречен на провал.
Почему я придерживаюсь мнения, что какой-никакой, но РП нужен в любом, даже самом маленьком (на одного исполнителя) проекте?
Ну, помимо очевидной необходимости скинуть с эксперта функции по своевременному формированию первички по Графику работ и Графику оплат, есть еще и психологическая потребность Заказчика услышать в трубку уверенный голос РП, который авторитетно заявляет, что «все под контролем» и «все будет хорошо». В любом проекте бывает момент, когда что-то выходит из под контроля, выявляются какие-то нежданчики в ресурсах, входящих данных, технологических ограничениях и прочее…
Вот тут, я считаю, и должен быть коронный выход РП: «don`t panic».
Недавно мне звонил клиент, как РП его проекта, который ВНЕЗАПНО осознал уровень сложности своей специфической отрасли. Все 15 минут переговоров свелись к тому, что я заверила, что мы эти сложности оценили на этапе пресейла, и если не появилось новых запросов, мы доведем начатое до успешной сдачи всех работ.
Руководитель проекта со стороны Заказчика
Не побоюсь сказать, что это САМАЯ ВАЖНАЯ РОЛЬ на проекте.
Сколько проектов миллионников проваливалось на этапе Start up из-за саботажа пользователей, организационной неразберихи, несоответствии целей проекта реальным производственным потребностям в автоматизации. У меня были клиенты со сложным наукоемким производством (навигационное оборудование), у которых на этапе запуска приходилось брать за руку Кладовщика и вести его к полке, где лежали детали и готовая продукция, участвующие в заказах на переработку (кооперацию), и физически раскладывать по полкам: слева — детали до гальваники, справа — после. Вся эта ситуация усугублялась не только тотальной бесхозяйственностью (здесь не об этом речь), а тем, что менеджер по кооперации делал Заказ на переработку в системе (один из самых простых документов, в данном случае, т.к. материалы, это тот же выпуск, только до гальванического покрытия) так:
- закладка заказа — 72 штуки
- выпуск — 80 штук
- материалы — 60 штук
Ответственность Заказчика не заканчивается поиском и заключением договора с Подрядчиком. Хотя и на этом этапе Заказчик должен подготовить документацию (или хотя бы ответы на вопросы) по:
- Оргструктуре предприятия
- Внутренних положениях и регламентах
- Должностным инструкциям целевой аудитории автоматизации
- Пользовательским инструкциям к эксплуатируемым ими АСУ
- Сформулированным целям проекта, а желательно — формализованное ТЗ
В течении проектной работы РП Заказчика организует встречи, совещания, оперативность принятия решения по сложным вопросам, согласование документации и пр. РП Заказчика непосредственно участвует в организации и приемке тестовой эксплуатации.
На этапе обучения, РП Заказчика должен уже быть самым компетентным в методологии внедряемого АСУ на территории предприятия. А на этапе Start up — главным контроллером. Тогда сотрудникам Исполнителя не придется брать на себя функции РУКОВОДСТВА компанией Заказчика.
Кто этот семирукий и многоголовый сотрудник?
В моих проектах (учитывая что я — специалист по управленческому учету и самому управлению) — это либо Экономист компании, либо Генеральный директор, либо Директор по развитию, либо нанятый специалист Внедренец (сейчас очень популярно выводить руководство проектом на аутсорсинг), но только вкупе с top-менеджером самой компании. Последний вариант, как показала моя практика, самый эффективный.
Категорически недопустимо, когда такую важную роль Заказчик доверяет Руководителю IT департамента, новому линейному руководителю отдела, который является целевой аудиторией внедрения, или рядовому исполнителю. Данные люди не обладают соответствующими: компетенциями, полномочиями, статусом среди сотрудников компании.
Пока не включаю в свой пост описание ролей Архитектора решения и рядовых специалистов Исполнителя и Заказчика, пусть простят меня мои коллеги, иначе будет слишком затянуто.