Проблемы внедрения проектного подхода на примере компаний отрасли IT

Чем более неопределёнными становятся условия ведения бизнеса в стране и мире, в целом, тем чаще компаниям приходится применять в своей деятельности проектный подход.

Согласно ГОСТ Р 54869-2011, проект - это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.

Управление проектом - планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта [1].

Рост популярности проектного подхода в бизнесе связан также со следующими преимуществами и тонкостями ведения проектов:

• -  проект  конкретен (в  каждом проекте существуют строгие

ограничения по срокам, бюджету и качеству);

• -    проект детализирован (классическая декомпозиция позволяет максимально детализировать бизнес-процесс и спрогнозировать возможные риски);

• -    проект интенсивен (высокая степень компетентности руководителя и команды ведёт к высокой интенсивности и качеству рабочего процесса);

• -    проект гибок (вышеупомянутая компетентность и детализация в декомпозиции позволяют, при необходимости, использовать как привычный вотерфолл, так и agile-методы без риска для сроков, бюджета и качества);

• -    наконец, проект управляем, ведь большинство методов управления пришло в проектную деятельность из IT-сферы, где строго прописанные регламенты, которых зачастую столь не хватает классическому менеджменту, применяются уже давно.

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

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

Чаще всего встречаются следующие причины рисков:

• -    ошибки целеполагания и определения проекта, отсутствие сбалансированного подхода к стратегии внедрения;

• -    неадекватные ожидания участников проекта;

• -    отсутствие (недостаточность) поддержки высшего руководства и других ключевых участников;

• -    ошибки при построении команды проекта;

• -    недостаточная квалификация и мотивация персонала [2].

Зачастую необходимость введения проектного инструментария в компаниях, где, по сути, всегда велась проектная деятельность (строительство, реклама) осознают только сами проектники. Часто подобная ситуация складывается на предприятии, где существует IT-подразделение, использующее какие-либо методы управления проектами. Внутренние заказчики же такого подразделения могут даже не подозревать о существовании подобного инструментария.

При этом квалифицированным менеджерам проектов для популяризации специальных технологий приходится работать сразу в трёх направлениях:

• -    на уровень или несколько уровней вверх (следует убедить руководство в необходимости введения проектного подхода);

• -    на уровень или несколько уровней вверх вниз (следует убедить подчинённых, привыкших работать в рамках функциональной структуры);

• -    на одном уровне (зачастую менеджер ведёт проект, не зная, что такое декомпозиция, сетевой график и даже диаграмма Ганта).

Приведём пример на основе двух реальных кейсов реальных IT-компаний.

Кейс 1. Департамент крупной международной IT-компании, ведущий проекты разного объёма и продолжительности для внешних заказчиков.

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

По классификации В. Богданова, отношение проектов типа «мозги», «седина» и «процедура» в подразделении, примерно, 1 к 1[3].

Кроме того, подразделение постоянно испытывает нехватку человеческого ресурса – проекты отличаются по сложности и специализации, а отсутствие элементарных проектных инструментов не позволяет руководителям отслеживать занятость команды и своевременно распределять актуальные задачи.

Основными проблемами данного подразделения в отношении проектного управления являются:

• -    недостаточная квалификация функциональных руководителей, некомпетентных в вопросах проектного управления;

• -    отсутствие обучения проектному подходу на всех уровнях подразделения;

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

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

Кейс 2. Крупная федеральная IT-компания, занимающаяся разработкой и ведением нескольких федеральных порталов, совокупный трафик которых достигает 17 млн посетителей в месяц.

Ежеквартально порядка 100 руководителей проектов-заказчиков запускают, примерно, 400 проектов разного объёма, сложности и себестоимости разработки. Проекты могут классифицироваться также по принадлежности к определённому порталу и определённой группе разработки. Примерно, в 70% случаев преобладают проекты типа «мозги». Исполнителями являются разработчики, ведущие проекты по гибкой технологии Scrum.

Ежеквартально заказчики и исполнители сталкиваются со следующими проблемами:

• -    заказчики не имеют ресурсов для мониторинга и контроля инициированных ими проектов, попавших в разработку;

• -    заказчики не имеют ресурсов для мониторинга проектов, находящихся в разработке у других проектников;

• -    этапы инициирования и закрытия проектов затягивается из-за отсутствия необходимых регламентов;

• -    недостаток контроля повышает риск несоблюдения всех важных ограничений проекта.

В данном случае также необходим вывод ведения проектов на качественно новый уровень:

• -    введение единой терминологии;

• -    определение единых процессов;

• -    определение проектных технологий и ПО, удовлетворяющих всех участников не только проекта, но и общего по всем порталам портфеля проектов;

• -    аудит нынешней ситуации, проектирование и внедрение релевантной корпоративной системы управления проектами по компании, в целом.