Практика применения ГОСТ Р 54869-2011 (Управление проектами) в государственной компании
: Практика применения ГОСТ Р 54869-2011 (Управление проектами) в государственной компании
Практика управления проектами в России долгое время не была стандартизирована на государственном уровне. 22 декабря 2011 г. был утвержден ГОСТ Р 54896-2011 «Проектный менеджмент. Требования к управлению проектом», ставший официальным источником методологии управления проектами (УП). Для лучшего понимания вопроса обратимся к его истории. Выпуском стандартов могут заниматься коммерческие и международные организации (например, International Organization for Standardization, ISO), профессиональное сообщество, а также государство. В последнем случае стандарты — это способ государственного упорядочивания деятельности компаний. Фактически система стандартизации в России действует более 80 лет. Основной категорией стандартов в СССР были государственные стандарты, в настоящее время на территории СНГ применяются межгосударственные стандарты. Документы, утвержденные до 1996 г., являлись нормативно-правовыми актами и поэтому были обязательными для применения в областях, которые определялись в их преамбулах. Нормативность документов, принятых после 1996 г., сама по себе перестала означать их обязательность. К их числу относятся и стандарты ГОСТ Р по управлению проектами, программами и портфелями проектов.
Очень важно, чтобы все участники проектной деятельности использовали единую базовую терминологию, работали в едином понятийном пространстве, поскольку реализация проектов — особый вид деятельности, часто имеющий высокий уровень неопределенности, обусловленный участием в нем значительного количества заинтересованных сторон. Без стандартизации требований к процессам управления, документам и результатам проекта невозможно добиться эффективного взаимодействия участников проектной деятельности.
ГОСТы по проектному менеджменту
На сегодняшний день в семейство стандартов «Проектный менеджмент», утвержденных Приказом Федерального агентства по техническому регулированию и метрологии от 22 декабря 2011 г. №1582-ст , входят:- ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»;
- ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» ;
- ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой» .
Разработчики ГОСТов учли общемировые тенденции стандартизации, к которым относятся взаимосвязь процессов управления (как на уровне отдельных проектов, так и на уровне программ и портфелей) и разделение базовых требований к процессам управления проектами и возможным (рекомендуемым) процессам, методам и инструментам. тандарт дает четкие и емкие определения основных терминов, необходимых для описания процесса управления проектом.
Данная статья не ставит целью сравнить ГОСТ Р 54869-2011 с «Руководством PMBOK®» PMI или стандартом ISO 21500, в последнее время появилось достаточно много подобных материалов, а посвящена описанию практики использования стандарта в конкретной российской госкорпорации и опыту автора.
Уникальность рассматриваемой компании обусловлена тем, что она относится к госсектору и вместе с тем ее деятельность имеет коммерческую составляющую. Можно утверждать, что перед компанией стоит амбициозная цель — зарабатывать деньги для государства, вследствие чего она является объектом пристального внимания со стороны всех компетентных контролирующих органов.
Риски применения ГОСТ Р 54869-2011
Стандарт ГОСТ Р 54869-2011 очень востребован в госструктурах. Он позволяет отойти от понимания проекта как комплекта документации, а проектной деятельности — как технологии ее разработки и может использоваться в качестве основного подхода к организации работы проектно-ориентированной компании. Часто проектное управление в России напоминает знаменитый диалог Алисы и Чеширского кота из «Алисы в стране чудес» Льюиса Кэрролла:
«— Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно... — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— ... только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.»
В начале проекта команда с энтузиазомом приступает к его выполнению, при этом игнорируя любые препятствия на своем пути. В качестве препятствия может восприниматься, например, необходимость оформления документации должным образом. Однако проекты осуществляются в конфликтной среде, и поэтому возникновение разногласий — их неизбежная составляющая. Незафиксированные документально договоренности приводят к серьезным конфликтам, которые невозможно разрешить, т.к. у устных соглашений в подобных ситуациях нет правового статуса. Это происходит из-за того, что с самого начала нарушается главный постулат проектного управления — последовательность в организации УП. Прежде чем осуществлять какие-либо действия, необходимо, чтобы заказчик сформулировал цель, затем нужно детализировать ее, создать команду, распределить роли, разработать план, согласовать бюджет и продумать риски.
Остановимся на рисках подробнее. Часто к нарушению сроков и превышению бюджета приводит именно невнимательное отношение к проектным рискам. В ГОСТе Р 54896-2011 риск определяется как «вероятное для проекта событие, наступление которого может как отрицательно, так и положительно отразиться на результатах проекта». Данное определение не является общепризнанным ни в международной, ни в российской практике. У автора данной статьи подобная формулировка вызывает некоторое недоумение: непонятно, почему событие уже определено как вероятное и указаны только результаты проекта. Существующая трактовка риска малоприменима на практике, т.к. часто управление проектами осуществляется «интуитивно». В части работы с рисками ГОСТ явно требует усовершенствований и дополнений.
Для предприятий госсектора типична ситуация, когда для управления проектом привлекаются высокопрофессиональные сотрудники, каждый из которых является уникальным в своем роде специалистом, но у команды в целом нет общего видения, стратегического подхода к решению поставленных задач.
Предприятие, о котором пойдет речь в данной статье, предоставляет широкий спектр телекоммуникационных услуг. Оно имеет статус Федерального государственного унитарного предприятия (ФГУП), контролируется и регулируется государством.
Красно-синий карандаш и ГОСТ Р 54869-2011
В компаниях, подобных рассматриваемой, применяется инструмент регулирования, который можно назвать «красно-синий карандаш». Принимая документ к рассмотрению, чиновник использует красную сторону карандаша для резолюции «отказать», а синюю — для резолюции «в работу», при этом следуя бюрократическим процедурам, что приводит к постоянным задержкам. В такой ситуации планирование становится невозможным, т.к. на обдумывание и формулировку целей и задач для согласования на разных уровнях организации необходимо время, а цели и сроки определяются директивно. Таким образом, можно утверждать, что зрелость такой компании по шкале развития проектной методологии имеет значение ниже нуля. Фактически проекты осуществляются, и многие даже успешно. Отметим, что это происходит отчасти благодаря руководящей роли государства, которое обязало ФГУП рачительно использовать его имущество и увеличивать капиталы: если бы не было этой коммерческой составляющей — не было бы и проектов. Однако с методологической точки зрения ситуация выглядит катастрофически: наблюдается путаница в терминах, определениях и понятиях. В компании одновременно осуществляется регулирование ее деятельности посредством бюрократических процедур и управление проектом в его коммерческом понимании.
Первое подразумевает отношение к проекту как к пачке бумажных документов или чертежей. Сроки при этом устанавливаются приказами, в которых указываются ответственные лица, не обладающие какими-либо реальными полномочиями. Это связано с тем, что компания имеет жесткую функциональную структуру, не предполагающую, что специалист, который находится на нижнем уровне служебной иерархии, может быть руководителем проекта.
Немаловажную роль здесь также сыграло то, что согласно существующим нормативам и законам, невозможно сделать запись в трудовую книжку сотрудника, выполняющего обязанности руководителя проекта, т.к. в классификаторе профессий такой профессии нет. Если для других компаний этот документ носит рекомендательный характер, то структура, подобная описываемой, опирается на него как на обязательный.
Другая сторона деятельности предприятия связана с осуществлением проекта в его коммерческом понимании. В этом случае у проекта должен быть руководитель, который планирует ход его выполнения от начала и до конца, подбирает и структурирует команду, готовит отчеты для руководства, отвечает за результат и достижение целей проекта. При этом должны быть сформулированы цели проекта, установлены его сроки, определены кураторы и заказчики, описаны их обязанности и полномочия.
Нетрудно представить, каким образом выполнялись проекты в описанных выше условиях до принятия ГОСТа Р 54896-2011. В ситуации, когда руководитель проекта не мог сам формировать команду, отвечать за сроки проекта и контролировать его ведение, проект в лучшем случае был обречен на вялотекущее выполнение с бесконечным ожиданием корректировок «сверху», а в худшем — на закрытие в фазе планирования. Резолюции, вынесенные с использованием красной стороны инструмента регулирования, о который мы упоминали ранее, — «отложить», «доработать», «отправить на рассмотрение» и т.п.— могли тянуться бесконечной вереницей.
Западный опыт в России
Возможность применения западных методик УП, например PMBOK, на предприятиях госсектора воспринималась негативно. Руководство считает, что в России для управления проектами характерны свои особенности, и поэтому должны применяться свои регулирующие механизмы. Было очевидно, что необходим документ, законодательно утверждающий проекты и проектную деятельность — стандарт либо иной нормативный акт, в котором были бы формализованы требования к процессу получения результатов, результату этого процесса и продуктам проекта, дано целостное представление об управлении проектами как отдельной области менеджмента, определено единое понимание общей последовательности процессов управления проектами и требований к отдельным процессам. Кроме того, такой документ должен был способствовать развитию дисциплины управления проектами, обобщению передового опыта и практики УП. При разработке стандартов были учтены как общемировые тенденции стандартизации, так и ее российские особенности.
Рассмотрим ситуацию, в которую попала проектная команда компании при осуществлении проекта IT-службы. Руководство поставило перед командой масштабную и очень важную для предприятия задачу комплексной автоматизации управления. Однако во время выполнения проекта команда не имела инструментов для ведения проектной документации согласно общемировой практике. В ее распоряжении было только «Руководство PMBOК», однако при осуществлении своей деятельности ФГУП как госкорпорация обязана опираться только на официальные документы, поэтому команда не могла применять его в своей работе. Например, использование в документах формулировки «Устав проекта» было отвергнуто с комментарием: «Устав у компании должен быть только один». Сложные задачи, которые стояли перед командой проекта, невозможно было начать решать без серьезной работы над документацией. Из-за бюрократических задержек в определенный момент управление проектом было приостановлено. Появление официального стандарта стало для команды проекта «спасательным кругом».
Главное различие между ГОСТом Р 54896-2011 и «Руководством PMBOК» состоит в том, что первый не содержит обязательного списка документов, которые требуется подготовить для того или иного проекта, т.е. в нем нет нежелательных для российской практики формулировок, таких как, например, «Устав проекта».
Согласно рекомендациям ГОСТа Р 54896-2011, в рассматриваемой компании используются следующие документы:
- Приказ о начале проекта;
- Приказ о создании менеджерской группы, которым утверждаются:
- Полномочия руководителя проекта;
- Состав проектной команды;
- Размер мотивационных выплат;
- Основные фазы проекта;
- График выполнения работ;
- График отчетности;
- Приказ о закрытии проекта.
