Управление ИТ-проектами

Существует огромное количество определений, как самого понятия «проект», так и связанного с ним термина «проектное управление». Фактически, большинство развитых стран имеют свои стандарты по управлению проектами, которые включают в себя необходимые определения. В России это ГОСТ Р 54869-2011 «Проектный менеджмент.  Требования к управлению проектом». Дальнейшее изложение этой главы в основном опирается на данный стандарт.

ГОСТ Р 54869-2011 даёт следующие определения:

Проект — комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.

Управление проектом (УП) — планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов. Приведём другие наиболее распространённые определения проекта.

Проект — это временное предприятие (усилие), осуществляемое (предпринятое) для создания уникального продукта или услуги. (PM BOK 2004).

Проект — это уникальный процесс, состоящий из набора взаимоувязанных и контролируемых работ с датами начала и окончания, предпринятый для достижения цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам. (ISO/TR 10006:1997 (E). Quality Management — Guidelines to quality in project management — p. 1).

Проект — это уникальная совокупность скоординированных действий (работ) с определёнными точками начала и окончания, предпринятая индивидуумом или организацией для достижения определённых целей с установленными сроками, затратами и параметрами выполнения. (British Standard BS 60791:2000. Project management — Part 1: Guide to Project management — p. 2).

Роли проекта. Проектный подход подразумевает в обязательном порядке выделение отдельной организационной структуры для управления проектом. Она может в значительной степени различаться в зависимости от специфики, но в каждом проекте должны быть определены следующие роли (согласно ГОСТ Р 54869-2011):

• заказчик проекта — физическое или юридическое лицо, которое является владельцем результата проекта;

• руководитель проекта — лицо, осуществляющее управление проектом и ответственное за результаты проекта;

• куратор проекта — лицо, ответственное за обеспечение проекта ресурсами и осуществляющее административную, финансовую и иную поддержку проекта;

• команда проекта — совокупность лиц, групп и организаций, объединённых во временную организационную структуру для выполнения работ проекта.

Кстати, когда мы говорим о заказчике, необходимо понимать, что это не единая роль. В ней всегда выделяются несколько лиц. Обычно есть топ-менеджер, отвечающий за проект со стратегической точки зрения (есть разные названия: владелец, спонсор и т.д.), и сотрудник бизнес-подразделения, глубоко вовлечённый в проект (ключевой пользователь, лидер проекта, ответственный за проект и т.д.), а также конечные пользователи системы.

Заинтересованные стороны в проекте (stakeholders) — это лица или организации, чьи интересы могут быть затронуты в ходе реализации проекта. Они часто не являются  непосредственными участниками проекта, но при планировании проекта необходимо оценивать их реакцию на выполняемые работы и управлять ею.

Жизненный цикл проекта — это совокупность этапов и фаз проекта. Для обеспечения более качественного управления проект разделяют на этапы и фазы. Во многих организациях существует чёткая стандартизация этапов, на которые должен делиться проект.

Базовый план проекта — это принятый к исполнению план проекта, содержащий сведения об основных временных и стоимостных параметрах проекта. Базовый план является основой для сравнения фактических показателей проекта с запланированными, для оценки хода выполнения проекта. Употребляется с уточнениями (базовый календарный план проекта, базовый бюджет проекта).

Изменение в проекте — это модификация утверждённого ранее содержания, сроков, ресурсов, а также установленных процедур. Поскольку проект, согласно определению, есть создание чего-то уникального, то изменения являются его неотъемлемым спутником. Грамотная организация управления изменениями — одна из наиболее критичных частей управления проектом.

Рис. 1. Взаимосвязи основных сущностей и субъектов проектного управления.

Что даёт управление проектами?

Сначала несколько слов о том, зачем нужно управление проектами. Знаменитый опрос CHAOS Chronicles, проведённый The Standish Group (Рис. 2), показал, что в 2009 году в мире только 31% ИТ-проектов завершились успешно, а 23% полностью провалились. В 2013 году картина была уже несколько лучше, чем в 1994, но динамика явно недостаточна.

Рис. 2. Статистика реализации ИТ-проектов в мире (The Standish Group).

Общей статистики по российским проектам, к сожалению, нет. Существует единственное исследование Hewlett-Packard и Economist Intelligence Unit, согласно которому, только 5% российских ИТ-проектов завершаются в срок.

Те, кто утверждает, что провалы — это специфика именно ИТ-проектов, не правы: та же проблема существует, например, и для очень крупных инфраструктурных проектов. Согласно исследованию, проведённому среди 258 инфраструктурных проектов с общим бюджетом более 90 млрд долл., 9 из 10 проектов сталкиваются с превышением бюджета. И в том, и в другом случае главной проблемой является сложность проектов. Для инфраструктурных проектов это статическая сложность: большие объёмы работ, большое количество техники, материалов, подрядчиков и т.д. Для ИТ-проектов проблема в динамической сложности — элементы системы (серверы, модули, интерфейсы) связаны нелинейными связями, и изменение одного вызывает слабо предсказуемую цепочку изменений в остальных.

Помимо вышеприведённых проблем  есть три серьёзные причины, которые подталкивают компании к внедрению проектного управления и управления программой проектов:

• Изменения в организации становятся все более сложными и комплексными.
• Достижение целей проекта требует тесного взаимодействия и вовлечения множества внешних сторон.
• Существующая организация, процессы и системы не поддерживают такой вид деятельности, как проект.

Управление проектом с использованием наработанных стандартных инструментов позволяет ощутимо повысить вероятность его успешного завершения, правда, в обмен на дополнительные затраты (зарплата проектного менеджера, стоимость создания планов, документации, отчётности и т.д.). Дополнительным бонусом идёт сокращение сроков и затрат проекта за счёт избежания непроизводительной, ненужной работы.И эффект от использования методологий и инструментов управления проектами весьма серьёзный. Исследование The Value of Project Management in IT Organizations, проведённое Center for Business Practices показало, что внедрение методов управления проектами улучшило 20 исследуемых показателей эффективности управления проектами в компании в среднем на 21%. Самые значительные положительные сдвиги были достигнуты в оценках сроков реализации проектов, соответствии проектов стратегическим планам компании, минимизации расходов, повышении продуктивности и качества реализации проектов. 97% менеджеров среднего звена ИТ-компаний, участвующих в управлении или реализации проектов, заявили, что введение методов управления проектами значительно повышает эффективность работы компании. Средний показатель возврата инвестиций на обучение и внедрение системы управления проектами на предприятии оценивается около 28%.

Ещё в 2000 году исследователи Kent Crawford и James Pennypacker провели опрос более 100 руководителей высшего звена, курирующих управление проектами. Исследование показало, что внедрившие управление проектами организации могут ожидать:

• увеличения успешно исполняемых проектов (достижение целей проекта) — в среднем на 50%;
• повышения оборачиваемости капитала — в среднем на 54%;
• повышения удовлетворённости клиентов — в среднем на 36%;
• повышения удовлетворённости персонала — в среднем на 30%.

Наконец, исследование российской ассоциации управления проектами СОВНЕТ показало, что профессиональное управление проектами позволяет сэкономить до 30% времени и до 20% средств.

При этом необходимо понимать, что управление проектом — затратная деятельность. Согласно мировой статистике, на управление проектом уходит от 2 до 15% бюджета самого проекта. Управление проектом имеет смысл и окупается только в том случае, если перед проектом стоят действительно серьёзные ограничения: по срокам, бюджету, качеству и т.д. Если же перед организацией и проектом серьёзных вызовов — конкурентных, нормативных, экономических и т.д. — нет, то управление проектами внедрять не имеет смысла, оно не будет работать.

Проекты и процессы

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

Рис. 3. Схема структурирования деятельности организации.

Задачей менеджмента организации является максимизация плановой деятельности и минимизация внеплановой. Это очень важный момент — управление по поручениям неплохо работает для небольших компаний в условиях быстро меняющегося окружения, но попытка управлять подобным образом крупной структурой приводит к серьёзным отрицательным последствиям. Эффективно управлять можно только плановой деятельностью.П

лановая деятельность, в свою очередь, подразделяется на процессы и проекты. У проектов и процессов есть общие признаки: они выполняются людьми, ограничены доступностью ресурсов, планируются, исполняются и управляются. Но есть и существенные отличия.

Повторяющаяся деятельность (процессы, операционная деятельность):

• периодически повторяется;
• понятна, имеет высокую степень определённости.

Создание нового (проектная деятельность):

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

Из различий в этих признаках возникают совершенно разные подходы к управлению. 

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

Граница между видами деятельности в реальной жизни часто условна — в зависимости от различных обстоятельств одну и ту же деятельность можно рассматривать и как проект, и как процесс. Например, доработка существующей и давно внедрённой на предприятии информационной системы, в зависимости от «масштаба бедствия», может рассматриваться и как процесс поддержки системы (создание нового отчёта), и как полноценный проект (изменение настроек системы в связи с изменениями правил регулирования рынка). Ещё один пример – проекты тиражирования существующих систем в региональные офисы. В зависимости от условий — трудоёмкости, необходимости дополнительных настроек — это может рассматриваться и как проект, и как процесс. Учитывая все эти особенности, организация должна ввести свои правила разделения проектной и процессной деятельности.

Основные вопросы, на которые при этом необходимо ответить: адекватно ли для того или иного вида деятельности использование проектных инструментов, позволит ли оно повысить эффективность работы при реализации задачи? При этом необходимо понимать, что если какая-то деятельность названа проектом, в ней обязательно должны быть реализованы некоторые требования (см. ГОСТ Р 54869-2011). В качестве примера классификации деятельности организации во врезке дан алгоритм выделения проектов, процессов и других активностей в АНО «Оргкомитет «Сочи 2014».

Заметим, что чёткое разделение деятельности на проекты и процессы не обязательно может применяться сразу ко всей организации. Этот же подход может быть использован и на уровне отдельного подразделения, например, ИТ-службы. В рамках ИТ-службы можно достаточно легко выделить стандартные процессы и проекты по развитию ИТ. Подробно инструменты управления процессами будут рассмотрены в главе «Управление ИТ-процессами и услугами».

В современной теории менеджмента также идёт проработка отдельной плановой сущности, не относящейся ни к проектам, ни к процессам – кейсов. Кейс выделяется в том случае, если существует высокая неопределённость, изменчивость окружающей среды. Эта область пока ещё недостаточно хорошо изучена и описана, хотя уже существует целый ряд систем управления кейсами – Adaptive Case Management.

Алгоритм разделения программ, проектов, мероприятий и процессов в АНО «Оргкомитет «Сочи 2014»

Оргкомитет «Сочи 2014» — это автономная некоммерческая организация, созданная для подготовки и проведения XXII Олимпийских зимних игр и XI Параолимпийских зимних игр 2014 года в городе Сочи. Вся плановая деятельность в Оргкомитете «Сочи 2014» делилась на 4 типа:

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

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

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

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

Алгоритм разделения программ, проектов, мероприятий и процессов следующий:

1. Активность классифицируется как Программа, если срок получения результатов больше 24 месяцев. В случае, если срок получения результатов составляет от 12 до 24 месяцев, активность может квалифицироваться и как программа, и как проект. Для программы должна быть проведена декомпозиция на проекты, процессы и мероприятия.

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

3. Активность классифицируется как Проект, если длительность получения результата больше трёх месяцев, либо трудоёмкость больше трёх чел/мес., либо бюджет более 1 млн руб.

4. Активность классифицируется как Мероприятие, если длительность получения результата меньше трёх месяцев, либо трудоёмкость меньше трёх чел/мес., либо бюджет меньше 1 млн руб., включая ИТ-компоненту с бюджетом более 10 тыс. долл.

Проект: работы и результаты

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

Соответственно, проект считается успешным, если он завершён:

• в полном объёме;
• в рамках бюджета;
• в установленные сроки;
• с заданным уровнем качества;
• при удовлетворении заказчика.

Отметим, что в разных проектах может быть разное представление об успешности: в каких-то проектах превышение бюджета (или срока) — это провал проекта, а других — совершенно не критично.

Сами работы в любом проекте делятся на две части: работы предметной области (например, для ИТ-проектов это создание кода, протяжка кабелей, установка серверов и т.д.) и работы по управлению проектом (создание планов, написание документов, проведение встреч, совещаний и т.д.). 

Основой управления проектом является составление плана работ и отслеживание хода работ по нему. При этом, постоянно идёт поиск компромисса между объёмом, сроками, бюджетом, качеством и удовлетворённостью заказчика с учётом имеющихся рисков.

Треугольник управления проектом

Для любого проекта выполняется следующее равенство, которое называют треугольником управления проекта или «первым законом управления проектом»:

Изменение одного из параметров проекта автоматически влечёт за собой изменение одного или нескольких других. Треугольником его часто называют потому, что основных параметров чаще всего считается три: сроки, бюджет, качество. В последнее время «по умолчанию» включают объем и удовлетворённость заказчика. «Геометрически» этот закон управления проектом может быть представлен таким образом: если «потянуть» один из отрезков (например, сроки), то, согласно правилам геометрии, изменятся и остальные. В русском языке этот закон отражён в известной поговорке «Мы сделаем вам быстро, качественно и недорого — выберите два из трёх». Важной особенностью связей между параметрами является их нелинейность и слабая предсказуемость. Особенно часто это проявляется в ИТ-проектах: одно небольшое изменение, например, объёма путём добавления нескольких новых требований может вызвать непропорциональное увеличение бюджета и/или сроков выполнения проекта.

Общий подход к выполнению проекта

В основе проектного управления лежит следующая идея: для получения заданного результата в проекте необходимо пройти следующую последовательность шагов.

1. Инициировать проект:

• чётко сформулировать цели проекта;
• определить кому он нужен — кто заказчик проекта, куратор проекта, определить всех основных заинтересованных лиц;
• назначить руководителя проекта.

2. Спланировать проект (сначала укрупнено, потом детально):

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

3. Выполнять и контролировать проект:

• выполнять, что запланировано и проверять результат на соответствие требованиям;
• при необходимости проводить перепланирование;
• принять результаты (продукт проекта).

4. Формально завершить проект:

• подписать все необходимые документы;
• премировать и распустить команду;
• подвести итоги проекта и сформировать архив.

Эта последовательность шагов достаточно универсальна и применима к любой предметной области.

Процессы управления проектом

Выше мы привели лишь некоторый минимальный перечень шагов. Более полно (и формально) управление проектами отражено в ГОСТ 54869-2011, согласно которому управление проектом включает совокупность нескольких ключевых процессов, которые объединены в пять групп: инициация, планирование, организация исполнения, контроль и завершение проекта (Рис. 4).

Рис. 4. Группы процессов управления проектом.

В полном объёме описание ключевых процессов управления проектом приведено в Табл. 1. Большинство существующих стандартов управления проектами с различной степенью детализации описывают примерно те же процессы. 

Табл. 1. Описание ключевых процессов проектного управления.

Стандарты управления проектами

Управление проектами является зрелой профессиональной сферой, но далеко не наукой. Фактически, управление проектами на текущий момент – это набор наблюдений, лучших практик, применение которых, как было кем-то и когда-то замечено, даёт положительный эффект. В этих условиях очень важную роль играют статьи, публикации и другие информационные материалы (они дают примеры этих практик), но особенно важную роль играют именно стандарты — при их разработке собираются, анализируются и сводятся в единый документ все достижения сообщества руководителей проектов.

Таким образом, стандарты по управлению проектами решают несколько задач:

• Концентрация лучшей практики (best practice) — стандарты в области управления проектами содержат лучший мировой опыт в этой области.
• Взаимодействие — стандарты являются основой взаимодействия и общей терминологии, особенно в больших и интернациональных проектах.
• Сертификация — стандарты являются основой для сертификации как организаций, так и отдельных специалистов в области управления проектами.
• Системная картина — стандарты отражают общую картину области менеджмента «управление проектами». Необходимо отметить, что подавляющее большинство существующих стандартов не являются «истиной в последней инстанции» — это именно сборники идей в помощь проектному менеджеру, «ящик с инструментами», из которого менеджер должен создать набор, подходящий для его конкретного проекта. 

Наиболее юридически точно эта мысль выражена в американском стандарте PMBOK. 

Основной целью Руководства PMBOK является выделение той части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. 

Термин «выделение» предполагает подготовку обобщённого обзора, а не исчерпывающего описания. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большую часть времени, причём относительно их значения и пользы в целом существует консенсус. 

«Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. 

«Хорошая практика» не означает, что описываемые знания должны всегда одинаковым образом применяться во всех проектах; возможность их применения для каждого конкретного проекта определяется командой управления проектом.

Аналогичная ситуация сложилась и в области управления ИТ-процессами: ITIL — это не «истина в последней инстанции», а свод лучших практик и рекомендаций на их основе. Однако есть и исключения из этого правила. Например, все требования ГОСТ Р 54869-2011 являются обязательными для исполнения для всех проектов. Помимо этого, чаще всего как обязательные к исполнению, строятся корпоративные стандарты по управлению проектами.

Стандарты в области управления проектами разрабатываются органами стандартизации на международном и национальном уровне, а также профессиональными организациями в области управления проектами, наиболее авторитетными из которых являются следующие:

• Международная организация по стандартизации (ISO) опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов» и ISO 21500 «Руководство по менеджменту проектов».
• Международная ассоциация проектного менеджмента (International Project Management Association, IPMA) основана в Европе в 1967 году и объединяет 45 национальных ассоциаций (Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ). Основной стандарт, разработанный IPMA – ICB (IPMA Competence Baseline, 4-я версия выпущена в 2015 году) – определяет требования к квалификации специалистов в области управления проектами и является основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всём мире.
• Институт управления проектами США (Project Management Institute, PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. PMI основана в 1969 году в США и включает более 200 национальных отделений, в том числе несколько российских. PMI ведёт активную разработку стандартов в области управления проектами. Опубликованы 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов (The Standard for Program Management, Second Edition, The Standard for Portfolio Management, Second Edition и др.). Дополнительные стандарты определяют требования как к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определённых типов проектов (Practice Standard for Work Breakdown Structure, Practice Standard for Earned Value Management, Practice Standard for Scheduling, Practice Standard for Conjuration Management и др.).

По областям применения существующие стандарты могут быть разделены на следующие группы:

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

В России приказом Федерального агентства по техническому регулированию и метрологии (Росстандарта) от 27.08.2008 в техническом комитете по стандартизации ТК 100 «Стратегический и инновационный менеджмент» создан подкомитет «Менеджмент проектов», в задачи которого входит разработка серии стандартов по управлению проектами для России. В 2011 году Росстандартом утверждена серия российских национальных стандартов в области проектного управления:

• ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом».
• ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов».
• ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой».

Табл. 2. Классификация и сопоставление стандартов.

Как в России, так и в мире на сегодняшний день существуют значительные пробелы в стандартизации в области проектного управления. 

Основные стандарты, применяемые сегодня в мире, разработаны профессиональными организациями в области управления проектами (PMI, IPMA, национальными ассоциациями) и, как правило, не имеют официального международного статуса.

Стандарты управления ИТ-проектом

ИТ-проекты имеют свою существенную специфику. Поэтому, несмотря на то, что к ним применимы все вышеперечисленные общие стандарты по управлению проектами, в мире существует ряд стандартов, специально нацеленных на выполнение именно ИТ-проектов. Одним из наиболее известных и популярных стандартов является PRINCE2. Стандарт на настоящий момент позиционируется как универсальный, но разработан он был в 1989 в Великобритании именно для выполнения ИТ-проектов для нужд государственных органов. Большим преимуществом стандарта является его глубокая проработанность и гибкость.

Необходимо также отметить неизвестный у нас в стране стандарт Hermes, который обязателен для выполнения на всех государственных ИТ-проектах Швейцарии. Стандарт включает в себя подробное описание подхода и полный набор проектных шаблонов на всех официальных языках этого государства: английском, французском, немецком и итальянском.

Вопреки распространённому мнению, серия стандартов ГОСТ 34 не имеет отношения к управлению проектами. Этот стандарт относится к жизненному циклу автоматизированных систем. И, хотя он содержит отдельные элементы управления проектами (например, документы при создании автоматизированных систем), на него нельзя опираться при внедрении процессов управления ИТ-проектами в организации.

Существует также ряд документов, которые нельзя назвать стандартами в полном смысле этого слова, скорее, это разработанные различными организациями частные своды знаний и методологии по выполнению ИТ-проектов:

• Software Engineering Body of Knowledge (SWEBOK) — документ, созданный комитетом Software Engineering Coordinating Committee. Назначение SWEBOK — в объединении знаний по инженерии (разработке) программного обеспечения.
• Rational Unified Process (RUP) — методология разработки ПО, созданная компанией Rational Software (сейчас часть IBM), очень жёсткая, глубоко проработанная и «тяжёлая». Ввиду сложности внедрения используется редко.
• Microsoft Solutions Framework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft. Представляет собой согласованный набор концепций, моделей и правил. MSF описывает управление людьми и рабочими процессами в ходе разработки ПО.

Также практически у каждого крупного производителя бизнес-приложений существует своя стандартная методология внедрения: Project Management Method (PJM) / AIM у Oracle, Accelerated SAP (ASAP) / Global ASAP у SAP и т.д. Все эти стандарты опираются на международные стандарты управления проектами, в той или иной мере используют перечисленные выше стандарты и своды знаний по управлению ИТ-проектами. 

Следует отметить отдельный класс стандартов — семейство так называемых «лёгких» (Agile) методологий разработки ПО (X, Lean, Scrum и др.).

Особенности выполнения ИТ-проектов

Вопрос «Что такое ИТ-проект?» не так очевиден, как кажется на первый взгляд. Ведь ИТ-проект может быть частью большого бизнес-проекта, а может быть отдельным, самостоятельным проектом, при этом включающим существенную бизнес-часть (например, перестроение существующих бизнес-процессов). Один из примеров такого разделения дан во врезке.

Выделение ИТ-проектов в ТНК-ВР

Разделение бизнес-проектов и ИТ-проектов, а также соответствующих составных частей комплексных проектов, в ТНК-ВP было сделано введением понятия ИТ-компоненты проекта и производных от нее определений:

ИТ-компонента бюджета проекта (ИТ-компонента) — расходы на работы внутренних и внешних трудовых ресурсов ИТ-службы, аппаратное обеспечение, телекоммуникационное оборудование, лицензии, затраты на первый год поддержки, консалтинговые работы по разработке или настройке приложений, а также на расширение пропускной способности канала.

ИТ-проект (IT driven project) — проект, в котором ИТ-компонента составляет большую часть бюджета. Бизнес-проект с ИТ-компонентой (business driven project) — проект по развитию бизнеса, включающий ИТ-компоненту с бюджетом более 10 тыс. долл.

Приведённый во врезке вариант выделения ИТ-проектов не идеален, в других организациях подход может отличаться и, например, основываться на трудозатратах. Это не столь важно, главное — чётко определить, что именно мы будем называть ИТ-проектом. Если неправильно рассчитать и поставить планку слишком высоко, то множество работ, которые должны выполняться как проекты, будут вестись «как получится» с соответствующими результатами. Если же занизить планку, то небольшие простые задачи будут обременены необходимостью готовить проектные документы, что затянет их сроки и приведёт к демотивации персонала.

Чёткая идентификация ИТ-проекта важна из-за их особенностей. Можно выделить четыре наиболее важных из них (основные тезисы взяты из интервью бывшего исполнительного директора компании PM Expert Андрея Конусова):

• Первая отличительная особенность ИТ-проектов лежит на поверхности. Она заключается в том, что любой просчёт или ошибка, как правило, очень быстро становятся известными широкому кругу людей. Если, например, осуществляется замена сервера или настройка какой-либо информационной системы и происходит сбой, то все пользователи тут же узнают об этом. В отличие от этого, например, в маркетинговом проекте просчёты далеко не так очевидны. Можно в его рамках сделать все правильно, но, допустим, не в полном объёме учесть интересы целевой аудитории. И напрямую обвинить в этом упущении руководителя проекта довольно сложно, т.к. существует большое количество внешних факторов. В ИТ-проекте внешних факторов тоже предостаточно, но ассоциативный ряд «преступление — наказание» у участников выстраивается однозначно: кто реализовал проект, тот и виноват.
• Вторая особенность заключается в том, что в настоящее время многие ИТ-проекты имеют колоссальные бюджеты. В крупных организациях масштабы проектной деятельности в области ИТ измеряются десятками миллионов долларов. Большие бюджеты, в свою очередь, подразумевают больший уровень ответственности и, соответственно, больший уровень компетенции тех людей, которые этими проектами управляют.
• Третья особенность состоит в том, что реализация новых проектов происходит постоянно. Если, например, промышленное предприятие достаточно один раз построить, и оно будет работать, не требуя существенных регулярных инвестиций, то развитие ИТ-инфраструктуры в растущих компаниях требует больших и регулярных вложений.
• Четвертая особенность — разделение заказчика и исполнителя на уровне идеологии. Заказчиком, как правило, является бизнес, а исполнителем — ИТ-специалисты. В результате возникают трудности в выявлении требований и ожиданий от проекта, в формировании технического задания, возникают проблемы коммуникаций.

Оценка сложности ИТ-проектов

Существует большое количество разнообразных классификаций ИТ-проектов, но не существует одной общепринятой. Каждая крупная организация вводит свою классификацию для постановки внутренних целей и оценки сложности. Наиболее распространена классификация ИТ-проектов по сложности и по видам работ. Пример классификации ИТ-проектов по уровню сложности по 17 различным параметрам (на основе опыта ТНК-ВР), приведён в Табл. 3.

Табл. 3. Пример классификации ИТ-проектов.

Приведённая классификация определяет линейную одноранговую шкалу уровня сложности ИТ-проекта (низкая/средняя/высокая), которая часто применяется на практике, однако, в целом ряде случаев её оказывается недостаточно.

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

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

Пример обязательных и зависящих от профиля элементов управления проектами показан на Рис. 5. Развитие и обсуждение данного подхода можно найти на сайте трёхуровневой Российской инструментальной модели Rim-III.ru.

Рис. 5. Элементы управления проектом: обязательные и зависящие от профиля проекта.

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

Проекты реорганизации и консалтинговые проекты хотя и имеют свою специфику, но для ИТ-подразделений они обычно невелики по объёму. Инфраструктурные проекты могут быть очень сложны с технологической точки зрения, но, если не брать масштабные проекты вроде создания новых ЦОД или массового перехода пользователей на новую стандартную систему, они не очень сложны с точки зрения управления проектами. 

Инфраструктурные проекты чаще всего отличаются своей стоимостью, но не сложностью. 

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

Проекты внедрения ПО

Внедрение коробочного ПО (out-of-the-box) без доработки

Ниже мы опишем последовательность шагов и работы предметной области проекта, процессы управления проектом остаются теми же, что были описаны выше. Общая последовательность шагов при внедрении существующего на рыке программного обеспечения без его существенной доработки (например, установка системы «Консультант») показана на Рис. 6.

1. Определение требований. Данный этап является ключевым для проекта любого типа. Перед тем, как что-то делать, необходимо определиться, ЧТО именно нужно сделать. Требования должны быть зафиксированы в документе «Требования к системе».

2. Анализ рынка. Хотя российский рынок готового ПО значительно слабее развит по сравнению с западным, на нем представлено довольно большое количество систем. Для проведения анализа можно использовать Интернет, специализированные информационные источники (например, отчёты Gartner) или внешних консультантов.

3. Выбор системы. Выбор системы должен проводиться по некоторым формальным критериям, которые выводятся из документа «Требования к системе». Данные критерии можно разделить на три категории:

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

б) Функциональные и нефункциональные требования к системе. Каждый критерий должен соответствовать одному из требований к системе. Данные критерии должны быть чётко формализованы, чтобы по ним можно было провести однозначную оценку каждого требования для каждой рассматриваемой системы (например, «да/нет», «отлично/хорошо/средне/плохо/функция отсутствует» и т.д.).

в) Стоимость. Должна быть проведена сравнительная оценка стоимости лицензий и требуемого аппаратного обеспечения (различные системы могут существенно отличаться по требованиям к аппаратному обеспечению). Также в неформализованном виде стоит выписать обобщённые плюсы и минусы систем. Это особенно полезно для презентации руководству. При выборе системы важно помнить, что для программного обеспечения правило «дорого, значит хорошо» не работает. То, что хорошо для одних условий может быть совсем не хорошо для других.

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

5. Выбор подрядчика по внедрению (опционально). Для проектов внедрения стандартных систем выбор подрядчика не обязателен. Данная работа может быть выполнена сотрудниками ИТ-службы.

6. Разработка/согласование технического задания (опционально). Так как данный вид ИТ-проекта часто не предполагает проведения сложных работ по доработке и настройке системы, нет необходимости разрабатывать отдельный документ с подробным описанием работ и требований. Все необходимые работы могут быть формализованы в договоре поставки и внедрения.

7. Закупка лицензий и аппаратного обеспечения. Проводиться согласно правилам организации.

8. Установка, обучение, разработка инструкций по использованию системы. Данные работы могут проводиться параллельно. Для установки лицензий на рабочие места пользователей могут использоваться средства удалённого управления. Особое внимание необходимо уделить обучению, без его грамотного проведения установленное ПО будет использоваться неэффективно.

Внедрение приложений с адаптацией

Внедрение существующего на рынке решения системы с её настройкой под организацию (например, внедрение CRM и ERP-систем), является промежуточным вариантом между «чистым» внедрением и «чистой разработкой». Таким образом, этапы данного проекта являются некоторой комбинацией этапов других видов ИТ-проектов. Важно отметить, что в этих проектах очень велика роль бизнес-заказчика — без его плотного взаимодействия с проектной группой проект обречён на неудачу.

Особенности ИТ-проектов по внедрению приложений с адаптацией следующие:

• для проектов данного типа чаще всего необходимо привлечение внешнего подрядчика;

• совершенно необходимо разработать «Техническое задание» на настройку и доработки внедряемой системы;

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

• рекомендуется проводить опытную эксплуатацию после внедрения продукта до закрытия проекта.

Разработка программного обеспечения «с нуля»

Процессу разработки программного обеспечения присущи две основные проблемы:

1. Непредсказуемость. Причиной непредсказуемости процесса является гибкость программного обеспечения — запрограммировать можно практически все что угодно. Обратной стороной является что это «практически все что угодно» сильно затрудняет планирование, мониторинг и управление разработкой ПО.

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

Рис. .6. Последовательность шагов при внедрении программного обеспечения без его существенной доработки.

Контроль ИТ-проектов

Контроль проекта проектным менеджером — часть всех существующих стандартов управления проектами. Нужен ли ещё один уровень контроля — контроль самого проектного менеджера и выполняемого им проекта? В идеальном мире контроль за проектным менеджером (проектом) не нужен: проектный менеджер сам зафиксирует проблемы и открытые вопросы, определит круг заинтересованных лиц, передаст им нужную информацию и организует разрешение проблем наилучшим образом. Но так как наш мир не идеален, то у многих участников ИТ-проекта возникает насущная необходимость держать его под контролем. Прежде всего, это относится к CIO, который, как правило, сам не управляет ИТ-проектами, но обязан держать под контролем идущие в его организации ИТ-проекты.

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

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

Учитывая, что любой ИТ-проект, согласно своему определению, является предприятием с высокой степенью неопределённости (создание уникального результата), то для ИТ-проекта вопрос контроля актуален по определению. Тем не менее, в настоящий момент стандарты по внешнему контролю ИТ-проекта отсутствуют, в основном всё сводится к подготовке отчётности той или иной степени детальности.

Сложно сказать, насколько контроль реально помогает избежать провала проекта — на эту тему идут довольно серьёзные дискуссии, как теоретические, так практического свойства. Например, любимый ответ проектных менеджеров на просьбу как-то формализовать свою деятельность и детальнее отчитываться: «Вам шашечки или ехать?». То есть Вам документы готовить, или чтобы проект выполнялся? Тем не менее, плохая статистика успешности проектов говорит в пользу повышения степени контроля.

Так что же такое контроль? Контроль — это один из терминов, которым все интуитивно пользуются, но часто затрудняются дать его точное определение. При этом часто контроль путают с его «младшим братом» — мониторингом. В чем же разница? Согласно словарю по экономике и финансам:

Контроль (от фр. controle — проверка) — это процесс, обеспечивающий достижение системой поставленных целей и состоящий из трёх основных элементов:

• установление стандартов деятельности системы, подлежащих проверке;

• измерение достигнутых результатов и их сравнение с ожидаемыми результатами;

• корректировка управленческих процессов, если достигнутые результаты существенно отличаются от установленных стандартов.

#Контроль #Controle

Словарь по экономике и финансам

Таким образом, мониторинг — это только часть контроля, важная, но не единственная. Ключевое отличие контроля — это возможность принятия управляющих воздействий. Если вы можете только смотреть на ситуацию и более ничего — это не контроль, а мониторинг. Графически это показано на Рис. 7.

Рис. 7. Три составных элемента контроля.

Объекты и субъекты контроля

Как уже было указано выше, с формальной точки зрения для целей контроля проект можно представить, как состоящий из работ и результатов. С точки зрения контроля важны три области:

• работы по управлению проектом;
• работы предметной области;
• результаты проекта, включая промежуточные.

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

Субъекты, выполняющие контроль ИТ-проектов — это бизнес-заказчик (заказчик), непосредственные руководители менеджера проекта (в том числе и CIO), проектный офис компании, служба внутреннего аудита, а также руководство и проектный офис компании исполнителя. Две трети ИТ-проектов осуществляются при участии этих субъектов контроля. Хотя в зависимости от масштаба организации и масштаба проекта этот список может сужаться или расширяться, но практически никогда он не превращается в пустое множество.

Интересы и глубина погружения этих лиц в проект различна, но все они, так или иначе, заинтересованы в его успехе и видят (по крайней мере, должны видеть) контроль непосредственной частью своей роли. Наиболее эффективно работа над проектом протекает, когда эти роли непосредственно вписаны в корпоративную методологию управления проектом, как, например, в процессе CVP (BP и ТНК-ВР), процессе G5 («Альфа-групп»), в методологии «Оргкомитета Сочи-2014» и др.

Построение системы контроля

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

Как же выстроить такую систему? К сожалению, готовых ответов не существует: слишком специфична практика управления проектом для каждой организации. На эту специфику накладываются стратегия организации, корпоративная культура, личностный аспект менеджмента и получается, что очень сложно говорить о некоей унифицированной стандартной для всех системе контроля. Но можно говорить о стандартной технологии построения системы контроля.

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

• Зачем контролировать?
• Что брать за эталон (с чем сравнивать)?
• Как влиять?
• Какие инструменты использовать?

Детально проработав вышеуказанные вопросы, можно получить адекватную каждому конкретному проекту систему контроля.

Зачем необходимо контролировать проект?

Не ответив на вопрос «зачем?» невозможно понять, насколько глубоко необходимо погружаться в проект. Ответы на эти вопросы зависят от той ситуации, в которой осуществляется контроль проекта, от соотношения субъектов контроля и природы самого проекта. Основных моментов, на которые здесь важно обратить внимание, также четыре. И именно они определяют индивидуальные особенности той или иной системы контроля проекта:

• уровень запроса — от кого поступил запрос на осуществление контроля: если от топ-менеджмента, то это один приоритет, если запроса не было, и это личная инициатива, то другой;
• стратегическая важность и срочность проекта — стратегический проект требует большего внимания, низкоприоритетный — меньшего;
• сложность и масштаб проекта — в проекте высокой сложности больше подводных камней и больше опасность провала, а значит, необходим более плотный контроль;
• опыт проектного менеджера — менее опытный менеджер проекта нуждается в большем контроле и поддержке, опытному проектному менеджеру меньше нужен контроль, более того, избыточный контроль будет его раздражать. 

Дополнительные критерии, которые могут повлиять на решение о необходимости и глубине контроля, перечислены в разделе о классификации ИТ-проектов (величина бюджета проекта, длительность проекта, влияние на корпоративную инфраструктуру и проч.). Эти оценки можно дать качественно, а можно формализовать, построив оценочную таблицу: например, по каждому из критериев проставить оценку от 1 до 3 и смотреть на итоговый балл по проекту. Чем выше балл, тем важнее проект с точки зрения контроля, тем больше инструментов нужно применять и тем глубже надо вникать в проект.

Поскольку ответы на эти вопросы очень индивидуальны, в результате использования вышеприведённой технологии у каждого субъекта контроля проекта получится своя индивидуальная система: у руководителя проектного менеджера одна, у CIO другая, у заказчика — третья. Наличие разных систем, разумеется, не является положительным аспектом, но, к сожалению, построить комплексную систему управления проектом, объединяющую всех участников и при этом их ещё и удовлетворяющую, получается далеко не всегда. Это возможно только при высоком уровне зрелости проектного управления в организации.

Что брать за эталон?

Как уже было показано выше, контроль – это всегда сравнение с каким-то эталоном. Значит, нужно определить, что брать за эталон для сравнения. Каких-либо единых, общих для всех, эталонных показателей по выполнению проектов, к сожалению, не существует. Все носят рекомендательный характер. Это несколько осложняет достижение договорённости с подрядчиком и бизнес-заказчиком о том, что именно мы понимаем под «нормальным управлением проектом». 

В любом случае, сравнивать можно и нужно с:

• нормативными документами самого проекта («Устав», «План», «Техническое задание» и т. д.);
• методологией и другими нормативными документами организации (если они есть);
• международными и отраслевыми стандартами (ISO, PMI, IPMA, PRINCE2 и т.д.).

Причём важно соблюдать именно такую последовательность: в первую очередь надо сравнивать с нормативными документами самого проекта, потом с методологией организации и только потом уже с международными стандартами. Хотя существующие международные стандарты слишком обширны и не выделяют минимальные критические требования к проекту, все же возможно выделить из них общие для всех требования. Не так давно появился стандарт ГОСТ Р 54869 «Требования к управлению проектом». Хотя, как и все остальные ГОСТ, он носит рекомендательный характер, тем не менее в нем чётко указываются, по крайней мере, обязательные управленческие результаты. 

Хотя существующие международные стандарты довольно сильно отличаются друг от друга, тем не менее, можно выделить из них общие для всех требования. 

На основе анализа этих требований можно уверенно сказать, что для ИТ-проекта любого масштаба и сложности есть ряд общих обязательных требований к документам и информационному обеспечению (см. врезку «Обязательные минимальные требования к ИТ-проектам»). Если перечисленных документов в проекте нет, то вряд ли подобную деятельность вообще можно назвать проектом.

Как влиять?

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

Ubi nil vales ibi nil velis — там где ты ничего не можешь, ты не должен ничего хотеть.

Древние римляне

Этот факт надо учесть при выборе и использовании инструментов. И, кстати, нужно ещё уточнить получится ли их применить — возможно, вам не удастся добиться даже просто получения отчётов по проекту.

Какие инструменты контроля использовать?

Теория и практика проектного управления на текущий момент располагает большим количеством инструментов, которые с успехом можно применять для целей контроля. На эту тему есть обширный список литературы, одной из наиболее полезных книг является «Набор инструментов для управления проектами» Драгана Милошевича. Как ключевые инструменты контроля, можно выделить (в порядке убывания степени формальности и повышения эффективности):

• аудиты;
• точки принятия решений (Ворота);
• экспертные отчёты (peer reviews);
• контрольные точки;
• отчёты проекта;
• собрания;
• встречи один-на-один.

Каждый из этих инструментов имеет свои плюсы и минусы, свою сферу применимости. И по каждому можно написать отдельную статью или даже книгу.

Особенно богатая тема по отчётам. Существуют, без преувеличения, тысячи различных форматов проектных отчётов. Но самым мощным инструментом, является точка принятия решений. В ИТ-проектах (и в инновационных проектах вообще) это очень важно — когда мы не знаем, что мы хотим получить в результате, нужно разбить проект на очень чёткие фазы, по которым осуществлять контроль. Надо сказать, что ещё более мощный инструмент — это, конечно, проектный офис. Когда у вас есть организационная единица, которая специально «заточена» на то, чтобы учить людей развивать процесс управления проектами и контролировать проект, это даёт максимальный эффект.

Определив инструмент, следует также определить и периодичность его использования.

Тёмная сторона силы

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

Во-вторых, и это гораздо опаснее, мало что так сильно раздражает работающего человека, как постоянный и мелочный контроль. Если все плотно контролировать, члены проектной команды перестают чувствовать свою ответственность за результаты работы и теряют мотивацию.Контролировать так, чтобы никто не вздохнул — это сильнейший демотивирующий фактор. Особенно это гибельно для проектных менеджеров. Придавленный, несамостоятельный руководитель проекта — уже совсем не менеджер проекта. Менеджером проекта де-факто становитесь вы.

В-третьих, контроль несёт за собой необходимость принимать решения и, соответственно, нести ответственность за результаты этих решений. Исчезает возможность сказать: «Ну, вот они тут все напортачили. Меня на них не было...».

Учитывая всё это, стоит сильно задуматься о том, насколько нужен контроль.

Экспресс-контроль проекта

Если по каким-либо причинам нет возможности строить полноценную систему контроля, но есть срочная необходимость прямо здесь и сейчас разобраться в том, что происходит на проекте, можно посоветовать использовать инструмент под условным названием «шестиугольник контроля». Этот «шестиугольник» определяет 6 основных направлений (углов) экспресс-контроля проекта:

1. Объем работ. Каковы цели проекта и ожидаемые результаты? Где описаны требования к результатам (Техническое Задание, Технические требования, Спецификация)? Каковы географические рамки и количество пользователей? Наконец, вопросы технологии: архитектура системы и используемые технологии.

2. Бюджет. План (кем утвержден), факт и прогноз. И, соответственно, расхождения плана и факта.

3. Качество. Какие есть критерии качества выполнения работ, критерии качества получаемых результатов? Кто должен принимать результаты? Где это прописано?

4. Выгоды. Какую проблему решаем? Какие выгоды ожидает заказчик от проекта? Как именно результаты проекта помогут решить проблему заказчика и/или принести выгоды заказчику (финансовые/нефинансовые, измеримые/неизмеримые)?

5. Ресурсы. Каков состав проектной команды, подчиненность, процент загрузки и есть ли проблемы с людьми? Насколько им нравится работать на проекте? Подрядчики: кто работает, как и кем были выбраны?

6. Сроки. Каковы этапы и основные вехи проекта? Полный план работ (кем утвержден), факт, прогноз.

Что конкретно нужно сделать для экспресс-контроля проекта? Надо получить проектную документацию, ознакомиться с ней и затем, сев на пару часов с проектным менеджером, пройтись вышеприведенными вопросами по основным направлениям, расширяя глубину обсуждения в случае необходимости. Если есть время и возможность, то 6 основных направлений экспресс-контроля можно дополнить шестью дополнительными направлениями контроля (ребра шестиугольника):

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

2. Утверждения. Кто участвует в согласовании и утверждении документов. Где это прописано.

3. Риски. Где описаны. Как отслеживаются. Как часто пересматриваются.

4. Открытые вопросы. Какие есть вопросы/проблемы и где они зафиксированы. Какие варианты решений. Кто и когда должен принять решение.

5. Коммуникации. Есть ли план коммуникаций. Какая информация, кому и когда она передается. А действительно ли она передается. А точно ли она передается. Когда последний раз передавалась.

6. Изменения. Были ли. Как отслеживаются и кем утверждаются. Журнал изменений. Предложенный подход даст не полную, но вполне целостную картинку по проекту и его состоянию. 

Есть и альтернативный вариант — пройтись по проекту не по предложенным направлениям, а с точки зрения областей знаний PMI PMBOK.

Система управления проектами в организации

Когда в организации начинает одновременно выполняться больше 5-10 проектов, встаёт вопрос о внедрении некоторого общего подхода. Сочетание организационной, методологической составляющей и информационной системы поддержки проектного управления в организации принято называть корпоративной системой управления проектами. При внедрении системы управления проектами всегда рекомендуется придерживаться последовательности: 

То есть сначала создать специальное подразделение, ответственное за внедрение управления проектами (офиса управления проектами, центра управления проектами), обучить людей проектному управлению, внедрить временную простую методологию. Затем разработать и утвердить детальную корпоративную методологию управления проектами. И только после этого внедрять информационную систему управления проектами. Отступление от этой последовательности быстро и болезненно отзовётся при внедрении системы управления проектами.

Существует два основных подхода к внедрению корпоративной системы управления проектами:

• на уровне всей организации — система охватывает все выполняемые организацией проекты;
• на уровне отдельного подразделения — чаще всего проектные офисы создаются в ИТ-службах.

В очень крупных организациях (Сбербанк, ТНК-ВР) внедряется двухуровневая система: Центральная корпоративная система управления проектами, задающая «общую рамку» и отвечающая за стратегические проекты и системы управления проектами подразделений.

Люди

Люди — это основной элемент корпоративной системы управления проектами. Без правильной работы с людьми система работать не будет. Дело в том, что внедрение системы управления проектами ощутимо меняет расклад сил в организации. Соответственно, требуется работа в четырёх направлениях:

1. Создание организационной структуры, отвечающей за проектное управление в организации — офиса управления проектами.Ни один бизнес-процесс в организации не будет работоспособным без поддерживающей его структуры — это в полной мере касается и проектного управления.

2. Проведение масштабного обучения сотрудников. Требуется, как минимум, трёхуровневая система обучения:

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

3. Создание системы мотивации сотрудников, привязанной к результатам проектов. Это критически важная задача. Если не поменять мотивацию людей, то внедрение с высокой степенью вероятности обречено на провал.

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

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

Никколо Макиавелли

Отдельно необходимо сказать о проектном офисе. Проектный офис — это подразделение или группа, которая определяет и поддерживает стандартные процессы, связанные с управлением проектами внутри организации. Существует две базовые модели проектного офиса. Первая — консультативный проектный офис, который выполняет консалтинговую роль, обеспечивая руководителей проектов в подразделениях методической поддержкой, обучением и рекомендациями по лучшему опыту выполнения проектов. Вторая модель — централизованный проектный офис, имеющий в своём штате руководителей проектов, которые выделяются подразделениям организации для работы над конкретными проектами. На то, по какой модели будет организован проектный офис и как будет укомплектован его состав, оказывает влияние большое количество организационных факторов, включая поставленные цели, традиционные влияния и культурные установки. Несмотря на то, что проектные офисы отличаются по размеру, структуре и обязанностям, существуют семь основных функций, которые может брать на себя проектный офис:

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

В исследовании проектных офисов компанией PM Expert были выделены следующие наиболее «популярные» функции, которые возложены на проектный офис в компаниях участниках опроса:

1. Функции по управлению проектами:

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

2. Функции по управлению ресурсами:

• наставничество и консультирование участников проектной деятельности;
• контроль распределения ресурсов в проектах;
• оценка эффективности руководителей проектов;
• организация и/или проведение обучения по управлению проектами.

3. Функции по управлению портфелем проектов:

• отслеживание портфеля;
• планирование портфеля (включая распределение ресурсов и разработку общего расписания);
• управление ресурсами портфеля.

Процессы (корпоративная методология)

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

Часто возникает вопрос: зачем организации нужна своя методология, если существуют признанные международные стандарты? На самом деле прямое использование их в организации практически невозможно. Как было указано ранее, они скорее являются набором «лучших практик», чем нормативным документом прямого действия. Необходима «привязка» к местным условиям: уточнение ролей и привязка их к организационной структуре, выделение именно тех процессов, инструментов и документов по управлению проектами, которые наиболее важны для проектов и культуры компании.

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

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

Технологии (информационные системы управления процессами)

При внедрении информационной системы управления проектами необходимо помнить ровно то же правило, что и для остальных систем: система подбирается под требования и задачи организации, а не наоборот. Информационную систему управления проектами невозможно просто поставить и начать работать. Как для ERP, CRM или других сложных систем, сначала необходимо понять потребности бизнеса, потом настроить под них систему. Настройки «по умолчанию» не работают. Разумеется, в данном случае речь идёт о корпоративной системе, а не о локально установленных приложениях. В качестве «рисовальщика планов» Microsoft Project прекрасно работает и без настроек.

Согласно исследованию компании PM Expert, наиболее используемые функции информационной системы управления проектами:

• календарное планирование и контроль сроков;
• учёт трудовых ресурсов;
• ведение проектной документации;
• управление бюджетом;
• табели учёта рабочего времени (таймшиты) сотрудников организации;
• управление рисками;
• управление потоками работ (workflow);
• ведение договоров и планирование поставок;
• учёт материальных ресурсов и механизмов.

Согласно последнему исследованию Gartner Magic Quadrant for IT Project and Portfolio Management, на международном рынке систем управления проектами установилась стабильность. За последний год количество и состав лидеров не изменился, а все вендоры стали ещё ближе друг к другу. Нельзя не отметить, что в последнее время начали активно набирать силу «лёгкие» SaaS-решения по управлению проектами.

Автор: Павел Алфёров

Источник: Учебник 4CIO. Настольная книга ИТ-директора

© Клуб Топ-менеджеров России 4CIO