Понятия управления проектами, проектного офиса, проектной команды и некоторые другие универсальны в рамках всех функциональных направлений деятельности компании. Вместе с тем термин «ИТ-проект», как бы тесно он ни был связан с решением бизнес-задач, по-прежнему устойчив. Насколько объективно правомерно подобное разделение, а в какой степени проектная деятельность универсальной? Об этом мы беседуем с Руководителя комитетва по стандартам СОДИТ, и Директора по стандартам 1С и обладателем международного сертификата по управлению проектами GAPPS. Мариной Аншиной.
Intelligent Enterprise: По каким принципам формируются проектный офис и проектная деятельность в компании? Каковы механизмы формального и неформального участия в нем ИТ-руководства или менеджеров проектов со стороны ИТ?
Марина Аншина: Взаимодействие проектного офиса и ИТ имеет два аспекта:
- проекты ИТ
- автоматизация проектной деятельности.
Остановимся на первом из них. Давайте сначала решим, что такое проекты ИТ.
ИТ-проекты в чистом виде встречаются крайне редко. Обычно проекты ИТ связаны с внедрением систем и одновременно с изменением бизнес-процессов, или проект ИТ является частью другого проекта. Поэтому в некоторых компаниях было принято следующее определение: проектами ИТ называются проекты, в которых затраты на ИТ составляют более 50% процентов бюджета. Можно также использовать временные оценки (более 50% затрат времени связаны с ИТ) или привлекаемые людские ресурсы (более половины членов проектной команды ИТ-специалисты). Числа могут быть и другими, 50% взяты для примера.
С другой стороны, часть, относящаяся к ИТ, все чаще присутствует в проектах. Поэтому менеджеры проектов со стороны ИТ участвуют в заседаниях проектного комитета, и директор по ИТ согласовывает планы всех проектов.
Знаю случай, когда в большом проекте по строительству нового цеха абсолютно не учли того, что в нем должны быть связь и компьютеризированные рабочие места. Результаты такой забывчивости оказались плачевны.
Проекты ИТ имеют свои особенности. Чтобы повысить их результативность и эффективность, полезно на основании корпоративной методологии ведения проектов сделать отдельную методологию ведения проектов ИТ.
При длительном внедрении серьезных информационных систем методики проектного управления часто привносятся крупными вендорами. Насколько они соотносятся (и должны ли соотноситься) с теми практиками, которые традиционно используются в компании для проектного управления. Должна ли быть здесь некоторая синхронизация, и если да, как лучше ее обеспечить?
Методики вендоров ERP-систем разработаны на основании международных стандартов и лучших практик. Их использование позволяет существенно сократить риски проектов и повысить их качество. Корпоративные практики обычно основываются на тех же международных стандартах (это прежде всего PMBoK, ISO/IEC 15288 и ISO/IEC 12207), поэтому не противоречат методикам вендоров. Если же речь идет о формате проектных документов, принятых в компании, и тех, которые использует компания, внедряющая систему, то надо стремиться использовать первые. Это хоть немного облегчит выполнение такого сложного проекта и обеспечит ему поддержку сотрудников компании-заказчика. Насколько я знаю, так всегда и поступают. Если же у заказчика корпоративного стандарта нет, то используются наработки внедренцев.
В любой компании, как известно, всегда существуют «классические» функциональные менеджеры. Кроме того, в менеджмент на тех или иных этапах развития бизнеса компании могут включаться антикризисные менеджеры, независимые директора, временные управляющие и пр. Можно ли говорить, что у каждого из них свой почерк в управлении вообще и в проектном управлении в частности?
По-моему, у любого специалиста в той деятельности, которой он занимается, есть свой почерк. Управление проектами – это искусство, поскольку всего в теории предусмотреть нельзя. Как и в других областях, тут есть свои законы, есть принципы ремесла, знание которых помогает, но не гарантирует успеха. Причем принципы управления проектами должны применяться с учетом особенностей конкретного проекта и среды, в которой он выполняется. Например, приемы антикризисного менеджера и руководителя организационного проекта, скорее всего, будут существенно отличаться.
Требовать наличия своего почерка, по-моему, бессмысленно. А вот при найме руководителя проекта очень полезно проанализировать, насколько его почерк соответствует принципам проектного управления нанимающей его компании и тому проекту, руководство которым ему собираются поручить.
Проектный менеджмент – весьма объемная дисциплина, в которую входят отдельные направления. Среди них управление требованиями, стоимостью, изменениями качеством, оценка рисков, разработка расписания и пр. Можно ли выделить какие-то направления, по которым требуется особая методическая синхронизация проектной деятельности в области ИТ и проектным управлением в компании в целом?
Чем больше областей синхронизируется, тем более гладко будут проходить проекты ИТ. Хотя бы потому, что в этой ситуации легче воспользоваться поддержкой, помощью и экспертизой проектного офиса. Как я уже говорила выше, разумно сделать корпоративный стандарт управления проектами ИТ на основании общекорпоративного стандарта проектного управления, в котором учесть особенности ИТ.
Давайте, например, посмотрим на управление бюджетом проектов. Если в компании принята методика выделения бюджета на проекты, то и проекты ИТ будут бюджетироваться по этой методике. К особенностям проектов ИТ относятся высокие риски и необходимость учета ТСО. Можно сделать соответствующее дополнение к корпоративному стандарту
Конечно, методики проектного управления зависят от ситуации, в которой действует компания. Они, как и осетрина, не могут быть второй свежести. Да и любые другие стандарты, впрочем. Например, при ключевой переориентации направлений деятельности понадобится уделить много внимания обучению и перепрофилированию персонала, а также мотивации.
Свидетельствами определенной квалификации в области проектного менеджмента могут быть многие признаваемые в бизнесе свидетельства и сертификаты. Какие формальные квалификации в сфере PM должны присутствовать у менеджеров в компании со стороны бизнеса и ИТ, чтобы проектные работы шли более гладко?
Трудно сказать что-то кроме банальностей, не зная ни конкретную компанию, ни конкретный проект.
Руководители проектов должны иметь достаточно полномочий и заручиться поддержкой руководства. Необходимо поднять престиж проекта, руководителя проекта и проектной команды. Проектные команды должны создаваться не по принципу избавления от слабых сотрудников, а наоборот, объединять наиболее компетентных и полезных для проекта специалистов. Нужны именно команды, использующие свои знания в области РМ для определенной компании в определенных условиях и для определенного проекта. Поэтому им всегда придется соблюдать баланс между теорией и практикой, идеальными условиями и требованиями обстоятельств.
В последнее время часто встречаются руководители проектов, которые, по сути, являются администраторами: следят за сроками и бюджетом, своевременным заполнением отчетных форм и проведением собраний, согласованием протоколов. Однако проект делается для того, чтобы получить полезный результат, а не только документы и выполненные графики. Об этом не стоит забывать.