Глава 4. Управление проектами

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

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

Рис 1. Статистика успешности ИТ-проектов CHAOS Chronicles (Standish Group)

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

Кстати те, кто утверждает, что провалы это специфика именно ИТ-проектов, не правы – та же проблема существует, например, и для очень крупных инфраструктурных проектов. Согласно проведенному исследованию 258 инфраструктурных проектов с общим бюджетом более 90 млрд. долл. 9 из 10 проектов сталкиваются с превышением бюджета[1].

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

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

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

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

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

•          увеличения успешно исполняемых проектов (достижение целей проекта) – в среднем на 50%;

•          повышение оборачиваемости капитала – в среднем на 54%;

•          повышение удовлетворенности клиентов – в среднем на 36%;

•          повышение удовлетворенности персонала – в среднем на 30%.

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

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

4.2 Основные подходы к управлению проектами

4.2.1 Определение проекта и управления проектами

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

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

·    Управление проектом (УП): планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта.

Дальнейшее изложение этой главы в основном опирается на стандарт ГОСТ «Проектный менеджмент. Требования к управлению проектом».

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

Управление проектами появилось как ответ на все возрастающую сложность создания новых продуктов и услуг. Если посмотреть на всю деятельность любой организации: благотворительной, коммерческой, государственной, то можно увидеть, что она делится на две большие группы: плановая и внеплановая (Рис. 2).

Рис 2. Виды деятельности организации.

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

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

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

·         как следует из названия, периодически повторяется;

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

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

·         уникальна, имеет ряд инновационных аспектов, нет опыта выполнения таких работ;

·         имеет четко заданные ограничения: дату завершения, ограниченный бюджет и т.д.

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

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

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

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

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

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

·         в полном объеме;

·         в рамках бюджета;

·         в установленные сроки;

·         с заданным уровнем качества;

·         при удовлетворении заказчика.

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

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

Рис 3. Разделение работ в проекте.

4.2.4 Треугольник управления проектом («Первый закон управления проектами»)

Для любого проекта выполняется следующее равенство:

f(Объем, сроки, стоимость, качество, удовлетворенность) = const

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

4.2.5 Важные сущности и субъекты проектного управления

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

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

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

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

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

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

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

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

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

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

Основные сущности и субъекты проектного управления и их взаимосвязь показаны на рис. 4.

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

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

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

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

–        четко сформулировать цели проекта;

–        определить кому он нужен - кто заказчик проекта, куратор проекта, определить всех основных заинтересованных лиц;

–        назначить руководителя проекта.

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

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

–        определить требования к результатам проекта;

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

–        установить связи между работами и их длительность, разбить работы на логические этапы, создать базовый план выполнения проекта;

–        определить риски проекта;

–        основываясь на имеющейся информации определить общий базовый бюджет;

–        сформировать проектную группу, распределить ответственность среди ее членов;

–        определить, как будет происходить обмен информацией в проекте;

–        договориться, что делать, если что-то меняется.

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

–        выполнять, что запланировано и контролировать результат на соответствие требованиям;

–        при необходимости проводить перепланирование;

–        принять результаты (продукт проекта).

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

–        подписать все необходимые документы;

–        премировать и распустить и команду;

–        подвести итоги проекта и сформировать архив.

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

Рис 5. Примеры этапов проектов в различных областях.

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

Выше мы привелилишь некоторый минимальный перечень шагов. Более полно (и формально) управление проектами отражено в ГОСТ «Проектный менеджмент. Требования к управлению проектом». Согласно ГОСТ управление проектом включает совокупность нескольких ключевых процессов, которые объединены в 5 групп: инициация, планирование, организация исполнения, контроль и завершение проекта (Рис. 6). В  полном объеме описание ключевых процессов  управления проектом приведено в таблице 1. Большинство существующих стандартов управления проектами с различной степенью детализации описывают примерно те же процессы.
 

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

Таблица 1. Процессы управления проектом по ГОСТ «Проектный менеджмент. Требования к управлению проектом».

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

4.5.1 Зачем нужны стандарты в управлении проектами?

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

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

1.       Концентрация лучшей практики (best practice) - стандарты в области управления проектами содержат лучший мировой опыт в этой области.

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

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

4.       Системная картина - стандарты отражают системную картину области менеджмента «управление проектами».

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

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

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

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

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

Международная организация по стандартизации (ISO) опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». В настоящее время выполняется разработка стандарта ISO 21500 «Руководство по менеджменту проектов»,однако официально данный стандарт будет утвержден только в 2012 году.

Международная ассоциация проектного менеджмента (International Project Management Association, IPMA) основана в Европе в 1967 году и объединяет 45 национальных ассоциаций (Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ). Основным стандартом, разработанным IPMA, является ICB (IPMA Competence Baseline, 3-я версия выпущена в 2006 году), определяющая требования к квалификации специалистов в области управления проектами и являющаяся основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России, разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире.

Институт управления проектами США (Project Management Institute, PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. PMI основана в 1969 году в США и dключает более 200 национальных отделений, в том числе несколько российских отделений. PMI ведет активную разработку стандартов в области управления проектами. В настоящее время опубликовано 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов (The Standard for Program Management, Second Edition, The Standard for Portfolio Management, Second Edition и др.). Дополнительные стандарты определяют как требования к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определенных типов проектов (Practice Standard for Work Breakdown Structure, 2nd Edition, Practice Standard for Earned Value Management, Practice Standard for Scheduling, Practice Standard for Configuration Management и др.).

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

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

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

·         Применимые к системе управления проектами организации в целом и позволяющие оценить уровень зрелости организационной системы проектного менеджмента. Некоторые наиболее известные стандарты международного и национального уровня представлены в таблице 2.

Таблица 2. Наиболее известные международные и российские стандарты в области управления проектами.

Насколько видно из таблицы в России и в мире на сегодняшний день существуют значительные пробелы в стандартизации в области проектного управления. Основные стандарты, применяемые сегодня в мире, разработаны профессиональными организациями в области управления проектами (PMI, IPMA, национальными ассоциациями). Данные стандарты, как правило, не имеют официального статуса на международном уровне. Основной международный стандарт ISO 10006 является очень кратким и носит общий характер. В этой ситуации, стандарты, разрабатываемые на национальном уровне, не опираются на единые международные требования и в значительной степени различаются между собой[2].

В России приказом Федерального агентства по техническому регулированию и метрологии от 27 августа 2008 г. в техническом комитете по стандартизации ТК 100 «Стратегический и инновационный менеджмент» создан подкомитет «Менеджмент проектов». Задачи данного подкомитета включают разработку серии стандартов по управлению проектами для России. Первые стандарты уже разработаны и находятся на утверждении.

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

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

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

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

·         Software Engineering Body of Knowledge (SWEBOK)[5] -- документ, созданный комитетом Software Engineering Coordinating Committee. Назначение SWEBOK — в объединении знаний по инженерии (разработке) программного обеспечения.

·          Rational Unified Process (RUP)[6] -- методология разработки ПО, созданная компанией Rational Software (сейчас часть IBM). Очень жесткая, глубоко проработанная и «тяжелая» методология. Ввиду сложности внедрения используется редко.

·         Microsoft Solutions Framework (MSF)[7] — методология разработки программного обеспечения, предложенная корпорацией Microsoft. Представляет собой согласованный набор концепций, моделей и правил. MSF описывает управление людьми и рабочими процессами в процессе разработки решения.

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

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

4.6.1 Определение ИТ-проекта и его особенности

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

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

Четкая идентификация ИТ-проекта важна из-за их особенностей. Можно выделить четыре наиболее важных из них[8]:

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

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

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

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

4.6.2 Классификация ИТ-проектов

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

Таблица 3: Классификация ИТ-проектов по сложности.

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

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

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

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

Рис 8. Классификация ИТ-проектов по видам работ.

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

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

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

Описание шагов:

1. Определение Требований. Данный этап является ключевым для проекта любого типа. Перед тем как что-то делать нужно сначала более-менее определиться, ЧТО именно нужно сделать. Требования должны быть зафиксированы в документе «Требования к системе».
2. Анализ рыка. Хотя российский рынок готового ПО значительно слабее развит по сравнению с западным, тем не менее, на нем представлено довольно большое количество программ. Для проведения анализа можно использовать Интернет, специализированные информационные источники (например, отчеты Gartner) или внешних консультантов.
3. Выбор системы. Выбор системы должен проводиться по некоторым формальным критериям, которые выводятся из документа «Требования к системе». Данные критерии можно разделить на три категории:

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

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

c.       Стоимость. Должна быть проведена сравнительная оценка стоимости лицензий и требуемого аппаратного обеспечения (различные системы могут весьма существенно отличаться по требованиям к аппаратному обеспечению).

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

4. Пилотный проект (опционально). Чаще всего по описаниям и документации очень сложно составить полное понимание системы. Коммерческие предложения производителя зачастую оставляют сомнение в своей адекватности. В таком случае единственным способом, который позволяет более-менее уверенно заранее утверждать, что данная программа подходит для нужд компании является проведение пилотного проекта, т.е. реальная инсталляция и использование программы в ограниченных масштабах.
5. Выбор подрядчика по внедрению (опционально). Для проектов внедрения стандартных систем выбор подрядчика не обязателен. Данная работа может быть выполнена сотрудниками ИТ-службы.
6. Разработка/согласование Технического задания (опционально). Так как данный вид ИТ-проекта часто не предполагает проведения сложных работ по доработке и настройке системы, нет необходимости разрабатывать отдельный документ с подробным описанием работ и требований. Все необходимые работы могут быть формализованы в договоре поставки и внедрения.
7. Закупка лицензий и аппаратного обеспечения. Проводиться согласно правилам компании.
8. Установка, обучение, разработка инструкций по использованию системы. Данные работы могут проводиться параллельно. Для установки лицензий на рабочие места пользователей могут использоваться средства удаленного управления. Особое внимание необходимо уделить обучению, без его грамотного проведения установленное ПО будет использоваться неэффективно.

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

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

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

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

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

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

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

Пример этапов проекта внедрения приложения с адаптацией приведен на рис. 10. Ввиду ограниченного объема учебника подробно рассматривать эти этапы мы не будем и отсылаем читателей к соответствующим информационным источникам.

Рис 10. Пример этапов проекта внедрения приложения с адаптацией согласно методологии внедрения ValueSAP (бывшая ASAP).

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

У нас в России все только людьми можно сделать и всякое дело надо держать не отпуская ни на минуту: как только отпустишь его в той мысли, что все идет само собой, то дело разоряется и люди распускаются и расходятся.
Обер-прокурор Синода К.П. Победоносцев, конец 19-го века

4.7.1 Необходимость контроля

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

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

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

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

4.7.2 Определение контроля проекта

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

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

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

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

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

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

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

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

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

•           работы по управлению проектом;

•           работы предметной области;

•           результаты проекта, включая промежуточные.

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

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

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

Рис 12. Субъекты, участвующие в контроле ИТ-проектов и взаимоотношения между ними.

4.7.4 Логика построения системы контроля

Невозможность контролировать все аспекты проекта требует выделить ключевые области и контролировать именно их. Для того чтобы контроль и, соответственно, управляющие воздействия были достаточно эффективны необходимо выстраивать СИСТЕМУ КОНТРОЛЯ, т.е. комплекс продуманных и взаимосвязанных мероприятий, выстроенный с учетом целей контроля. Она должна быть зафиксирована и донесена до подконтрольных лиц.

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

Но можно говорить о стандартной технологии построения системы контроля. Для построения системы контроля нужно последовательно ответить на 4 вопроса (рис 13):

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

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

Рис 12. Технология построения системы контроля проектов.

(Прим – слово «стандарт» меняем на «эталон»).

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

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

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

•          стратегическая важность и срочность проекта -- стратегический проект требует большего внимания, низкоприоритетный – меньшего;

•          сложность и масштаб проекта -- в проекте высокой сложности больше подводных камней и больше опасность провала, а значит, необходим более плотный контроль;

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

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

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

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

Как было уже показано выше контроль это всегда сравнение с некоторым эталоном. Значит нужно определить, что брать за эталон для сравнения. Каких-либо единых общих для всех эталонных показателей по выполнению ИТ-проектов к сожалению не существует, все носят рекомендательный характер. Это несколько осложняет достижение договоренности с подрядчиком и бизнес-заказчиком что именно мы понимаем под «нормальным управлением проектом». Международные стандарты (от PMI, IPMA, PRINCE2 и т.д.) к сожалению слишком обширны и не выделяют минимальные критические требования к проекту. Утверждаемый в настоящее время новый ГОСТ по управлению проектами должен ощутимо улучшить ситуацию.

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

•          с нормативными документами самого проекта («Устав», «План», «Техническое задание» и т.д.);

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

•          международными и отраслевыми стандартами.

Причем важно соблюдать именно такую последовательность: в первую очередь надо сравнивать с нормативными документами самого проекта, потом с методологией компании и только потом уже с международными стандартами.

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

Как влиять?

Ubi nil vales ibi nil veils – там где ты ничего не можешь, ты не должен ничего хотеть.
Древние римляне

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

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

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

•          аудиты;

•          точки принятия решений (Ворота);

•          экспертные отчеты (peer reviews);

•          интеграционные контрольные точки;

•          отчеты проекта;

•          собрания;

•          встречи один на один.

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

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

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

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

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

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

Рис 14. Зависимость трудозатрат при контроле проектов от глубины контроля.

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

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

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

Люди -> Процессы -> Технологии

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

Р

Рис 15. Состав корпоративной системы управления проектами.

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

·         внедрение на уровне всей компании -- система охватывает все выполняемые компанией проекты;

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

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

4.8.1 Люди

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

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

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

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

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

o   для руководителей проектов - детальный углубленный курс;

o   для сотрудников (участников проектных рабочих групп) - краткие курсы по основным положения проектного управления.

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

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

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

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

·         помощь проектным менеджерам — помощь по управлению проектами менеджерам в подразделениях;

·         методология — разработка и развитие методологии управления проектами;

·         обучение: проведение тренингов или постановка задачи по обучению для внешних провайдеров;

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

·         внутренний консалтинг и наставничество — распространение лучших практик среди сотрудников организации;

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

·         управление портфелем проектов.

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

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

o   контроль изменений и отслеживание проблем по проектам;

o   мониторинг эффективности выполнения проектов (анализ отклонений);

o   анализ результатов проектов по завершении;

o   контроль соблюдение методологии управления проектами;

o   анализ проектов на соответствие стратегии (на этапе инициации проектов);

o   обеспечение коммуникаций с функциональными подразделениями-заказчиками; проектов и поддерживающими службами;

o   управление отдельными проектами компании.

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

o   наставничество и консультирование участников проектной деятельности;

o   контроль распределения ресурсов в проектах;

o   оценка эффективности руководителей проектов;

o   организация и/или проведение обучения по управлению проектами.

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

o   отслеживание портфеля;

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

o   управление ресурсами портфеля.

4.8.2 Корпоративная методология/процессы

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

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

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

·    глоссарий;

·    основные термины и определения;

·    определение что такое проект, признаки выделения проекта;

·    классификацию проектов;

·    жизненный цикл проекта;

·    описание основных ролей;

·    документы проекта;

·    встречи и совещания;

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

·    систему отчетности;

·    шаблоны документов.

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

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

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

·         календарное планирование и контроль сроков;

·          учет трудовых ресурсов;

·         ведение проектной документации;

·          управление бюджетом;

·         табели учета рабочего времени (таймшиты) сотрудников компании;

·         управление рисками;

·         управление потоками работ (workflow);

·         ведение договоров и планирование поставок;

·         учет материальных ресурсов и механизмов.

Согласно последнему исследованию Gartner Magic Quadrant for IT Project and Portfolio Management, 2010[4]на международном рынке систем управления проектами установилась стабильность. За последний год количество и состав лидеров не изменился, а все вендоры стали еще ближе друг к другу. Нельзя не отметить, что в последнее время начали активно набирать силу «легкие» SaaS-решения по управлению проектами. Кроме наиболее известного из них Basecamp (http://basecamphq.com/)[5]. 

Рис. 16. Магический квадрат систем управления проектами (Gartner, 2010).