Этапы внедрения СУП не равноценны по длительности и ресурсоемкости. Они не обязательно выполняются жестко последовательно: часть этапов могут выполняться одновременно, например, организация проекта внедрения СУП и обследование, автоматизация проектной деятельности и формирование проектного офиса. Однако в любом случае выполнение всех этапов – обязательно. Возможно, вместо "классической" ИСУП может быть Excel. Проектный офис будет сформирован посредством возложения на одного из сотрудников дополнительных функций по ведению реестра проектов и контролю формирования проектных документов. Однако все составляющие СУП должны быть созданы и соответствовать друг другу по содержательному наполнению с учетом объемов проектной деятельности и специфики проектов в конкретной организации.
Далее более подробно рассмотрим три составляющие СУП, а именно: методологию управления проектами, ИСУП и проектный офис.
Рис. 6.1. Дорожная карта внедрения СУП -7 этапов
6.4. Методология управления проектами для организации
Методология управления проектами в организации представляет собой утвержденный пакет внутренних нормативных документов, в которых описаны процессы по управлению проектной деятельностью в компании и отражена совокупность практик, методов, процедур и правил. Такая методология обычно строится на базе методов проектного управления международных стандартов управления проектами, зарекомендовавших себя как совокупность "лучших практик" в дисциплине проектного менеджмента. Однако в каждой организации должна использоваться своя, уникальная методология, которая разработана с учетом специфики проектной деятельности предприятия, его организационной структуры и принципов принятия решений, уровня зрелости проектной деятельности.
Как правило, в крупных и средних компаниях есть внутренние стандарты по документированию процессов, с учетом которых нужно будет разрабатывать иерархию и структуру документов, описывающих и проектную деятельность.
Структура внутренних нормативных документов будет определяться также исходя из того, какими объектами управления решено формализовать управление: только проектами, проектами и программами или же проектами, программами и портфелем программ и проектов.
Рассмотрим случай, когда принято решение о стандартизации процессов управления всеми тремя объектами управления в области проектной деятельности: проектом, программой и портфелем. Возможна следующая иерархия проектных документов.
Уровень 1-й:
• Политика по управлению проектной деятельностью. Цель данного документа – описать роль и место проектного управления в управляющих процессах предприятия, определить, по каким критериям деятельность можно отнести к проектной, описать основные принципы управления проектами, программами и портфелем, а также организационную структуру управления проектной деятельностью и элементы системы управления проектами.
• Положения о коллегиальных органах, уполномоченных принимать решения в области проектной деятельности, о подразделениях, осуществляющих координацию и поддержку проектов (о проектном офисе).
Уровень 2-й:
• Регламенты по управлению проектами, программами, портфелем программ и проектов. Регламенты будут содержать карту и описание процессов.
Уровень 3-й:
• Шаблоны документов, которые используются в ходе процессов по управлению проектной деятельностью.
• Технологические схемы по выполнению процессов по управлению проектной деятельностью в ИСУП.
Иерархия документов вполне может быть упрощена, т. е. методология может состоять только лишь из одного регламента по управлению проектами, где шаблоны документов будут приложениями в рамках регламента. В данном случае в этом единственном регламенте нужно описать разделы, которые в более сложной структуре внутренних нормативных документов (ВНД) были бы в ВНД 1-го уровня.
До разработки регламентной базы рекомендуется договориться внутри команды внедрения СУП, в которую входят ключевые заинтересованные лица во внедрении СУП и методологи – разработчики ВНД, о том, какой из международных стандартов в сфере управления проектами станет основой для разработки регламентной базы при описании ролевой модели, областей знаний и списка процессов по управлению проектами. Выбор того или иного стандарта не означает, что нельзя использовать в дополнение те или иные аспекты из других стандартов.
В методологию по управлению проектами рекомендуется включить следующие разделы:
1. Основные понятия проектного управления, такие как "проект", "управление проектами", "этап", "веха", "календарный план проекта".
Не рекомендуется включать в данный раздел описание ролей (для этого будет отведена отдельная глава), описание артефактов, документов, общеизвестных терминов, не специфичных для УП (бизнес-процесс, информационные технологии, система). Аббревиатуры название подразделений организации лучше оформить в виде списка сокращений и вынести в конец методологии.
2. Роли в проектном управлении можно разделить на две группы: постоянные и временные участники.
Постоянные участники проектной деятельности выполняют определенные функции в части управления любым из проектов компании. К таким участникам можно отнести:
• Проектный комитет – коллегиальный орган, принимающий решения о целесообразности реализации проектов. К функциям данного комитета может относиться согласование запросов на значимые изменения проектов, распределение ресурсов между проектами, установка приоритетов по проектам, разрешение конфликтов между проектами, проектной и операционной деятельностью, назначение руководителей на наиболее критичные для предприятия проекты.
• Проектный офис – подразделение, являющееся центром развития и внедрения проектного управления в компании и осуществляющее общий контроль за реализацией проектов предприятия. К функциям проектного офиса может относиться формирование организационных стандартов управления проектами, обеспечение их соблюдения, выполнение функций секретариата проектного комитета.
• Обеспечивающие подразделения, отвечающие за отдельные процессы, связанные с обеспечением проектной деятельности, например, финансовый отдел, выполняющий финансово-экономическую оценку проектных инициатив, учитывающий расходы и прибыль от проектной деятельности при финансовом планировании.
Временные роли в проектной деятельности получают сотрудники компании в рамках конкретного проекта. Назначение на роль в проекте означает возложение определенных полномочий и обязанностей в контексте данного проекта.
Среди временных ролей, которые обязательно должны быть включены в проектную деятельность, можно выделить следующие:
• Заказчик. Типовой минимальный список функций: согласование целей, критериев успешного выполнения проекта, требований к продукту проекта, согласование запросов на изменения в проекте; подготовка предложений о приостановке или прекращении проекта вследствие нецелесообразности или невозможности дальнейшего выполнения; приемка результатов работ, включая промежуточные.
• Руководитель проекта. Типовой минимальный список функций: обеспечение успешного выполнения проекта; организация разработки документов, определяющих цели, задачи, требуемые результаты, общий план выполнения и бюджет проекта; планирование, организация и контроль выполнения работ по достижению целей проекта с требуемыми качеством, затратами и в запланированный срок; своевременная подготовка содержательной части конкурсной и договорной документации по проекту; назначение задач проектной команде (отдельным ее участникам) и контроль за их выполнением; требование от всех участников проектной команды выполнения работ по проекту и своевременной отчетности о текущей ситуации в порученной зоне ответственности; проведение переговоров с внешними компаниями, привлеченными для реализации проекта, и координация работ с подрядчиками и поставщиками; отслеживание рисков проекта и разработка планов реагирования на риски; инициация запросов на изменение содержания, сроков и бюджета проекта; регулярное и своевременное предоставление отчетности о ходе выполнения проекта.
• Куратор проекта. Типовой минимальный список функций: утверждение проектных документов; выделение ресурсов для выполнения проекта, контроль за ходом выполнения проекта; согласование изменений основных параметров проекта; административная поддержка проекта; разрешение конфликтов, эскалированных со стороны руководителя проекта, заказчика.
В список временных ролей также включают участника/исполнителя в проекте, руководителя рабочей группы в составе проектной команды, команду подрядчика, администратора проекта.
3. Классификатор проектов. Классификация разрабатывается, во-первых, для проведения аналитики по общему списку проектов компании с учетом их классификационных признаков. Например, чтобы получить сводную картину по проектам, какое количество ресурсов уходит на проекты развития тех или иных регионов; в проектах с привлечением каких подрядчиков наибольшие отклонения по срокам. Во-вторых, классификация нужна для того, чтобы с учетом значений классификационных признаков проекта использовать специфичные схемы управления данным проектом, описав их в методологии. Например, инновационные проекты требуют более тщательного управления рисками; проекты, заказчиками которых выступают несколько функциональных подразделений, должны управляться посредством управляющего комитета, в состав которого будут включаться функциональные руководители подразделений. Количество аналитических признаков, по которым можно группировать проекты, может быть произвольным, но на практике классификация более чем по 10 признакам является избыточной. Примеры классификационных признаков:
• по стратегической важности проекта (можно присвоить значения А – высший приоритет должны быть выполнены, даже если будет необходимо увеличить количество ресурсов на выполнение; В – стандартные проекты; С – низкий приоритет, проект выполняется только в случае простоя ресурсов);
• по стоимости;
• по жесткости сроков проекта (без возможности сдвига сроков, например, проекты по строительству олимпийских объектов в Сочи, или с возможностью сдвига сроков);
• по длительности (краткосрочный, долгосрочный);
• по уровню участия (по количеству вовлеченных подразделений);
• по опыту исполнения проекта (типовой или инновационный);
• по направлению деятельности (в зависимости от содержания результатов, например, маркетинговый, ИТ, строительный, проект по слиянию и поглощению и т. д.);
• внутренний/внешний проект (выполняется для внешнего или внутреннего заказчика).
4. Процессы управления проектами, упорядоченные по фазам жизненного цикла. Данный раздел является ключевым в нормативной базе. В нем должна быть представлена общая схема процессов по управлению проектами и дано описание каждого процесса (рис. 6.2).
В целом к описанию процессов по управлению проектами можно дать следующие практические рекомендации:
1. Процессы должны быть привязаны к последовательным этапам административного жизненного цикла проекта, который обычно состоит из четырех этапов:
• инициация (процессы, основным результатом которых является оформленное решение о выполнении/невыполнении проекта в компании);
• планирование (процессы по составлению планов проекта, их согласованию и утверждению и получению ресурсов в распоряжение руководителя проекта на основании утверждения проектных документов);
• реализация (процессы по выполнению работ, сдаче результатов работ заказчику, мониторингу работы подрядчиков и проектной команды, отчетности перед заказчиком и куратором проекта о выполнении проекта, управление изменениями в проекте);
Рис. 6.2. Пример карты процессов управления проектами с разбиением по фазам жизненного цикла проекта
• завершение (процессы по оценке успешности проекта, формированию извлеченных уроков, передаче документов в архив компании).
Перечисленные четыре этапа жизненного цикла проекта универсальны и не зависят от сферы деятельности компании.
2. Процессы по возможности должны быть выстроены последовательно, так как последовательная цепочка процессов дает однозначное понимание логики их выполнения.
3. Должна быть заложена возможность контроля выполнимости процесса, т. е. в конце процесса должен быть представлен документ или результат. В противном случае соблюдение процессов нельзя будет проверить силами проектного офиса и невозможно гарантировать, что методология управления проектами соблюдается.
4. Процессы должны быть детализированы в одинаковой степени при описании. Ни в коем случае не надо пытаться сделать количество процессов равным количеству процессов по управлению проектами в PMI PMBOK, например. Не все процессы PMI PMBOK имеют результат, который следует оформлять отдельным проектным документом.
Традиционно при описании процессов используют следующую структуру:
• назначение процесса;
• владелец процесса;
• участники процесса;
• документы на входе процесса;
• документы на выходе процесса;
• подпроцессы;
• описание последовательности шагов процесса или подпроцессов.
Описание процесса также сопровождается диаграммой процесса.
Те проектные документы, которые формируются при выполнении процессов по управлению проектами, должны быть снабжены шаблонами проектных документов в составе методологии.
Регламентная база по управлению проектной деятельностью должна обновляться по мере повышения уровня зрелости организации в области управления проектами. По мере внедрения методов управления проектами будут регламентироваться и вводиться в действие следующие процессы:
• управление пулом ресурсов с учетом занятости сотрудников в проектной и функциональной деятельности;
• мотивация сотрудников с учетом результатов реализации проектов;
• управление программами;
• управление портфелем проектов.
6.5. Информационная система управления проектами как средство автоматизации процессов управления проектами компании
Информационная система управления проектами – внедренное в организации программное обеспечение, используемое для автоматизации проектной деятельности в соответствии с методологией управления проектами, а также комплект сопроводительной документации по работе с данным программным обеспечением.
Существует отдельная ниша на рынке программного обеспечения: инструментарий для автоматизации управления проектами. Подобных программных продуктов довольно много, они отличаются по функциональным и техническим возможностям и соответственно по стоимости.
К базовому функционалу, поддерживаемому значительным числом информационных систем управления проектами, относится автоматизация следующих функций:
• Составление иерархической структуры работ, состава операций в проекте, разработка календарного расписания проекта с учетом взаимосвязей операций, длительности операций, календарей; расчет критического пути проекта; ввод фактических сроков работ, сохранение нескольких версий базового плана проекта, сравнение текущего календарного графика с базовым календарным графиком.
• Ведение справочника ресурсов (различные системы могут поддерживать или все виды ресурсов, включая машины и материалы, или только отдельные виды ресурсов, например, человеческие ресурсы или финансы), назначение ресурсов на операции проектов, анализ потребности в ресурсах на проектах, ввод фактического расходования ресурсов, в том числе табелей учета рабочего времени исполнителей, план-факт анализ расходования ресурсов.
• Ведение реестра рисков по проекту, назначение ответственных за управление рисками, планирование мер реагирования на риски.
• Получение различных видов отчетов по проектам, в том числе с использованием дополнительных аналитических справочников, обеспечение информационного обмена между участниками проекта.
• Поддержка мультипроектного управления, в том числе с точки зрения приоритетности проектов при распределении ресурсов.
• Ведение архива проектной документации.
Приведенный список функционала является основополагающим, многообразие настроек по каждой из функций зависит от конкретного программного продукта. В дополнение к перечисленным функциям в отдельных программных продуктах присутствуют расширенные возможности, например, анализ по освоенному объему, анализ рисков по методу Монте-Карло и т. д. Для того чтобы выбрать программный продукт для автоматизации проектной деятельности на конкретном предприятии, изначально нужно сформировать требования к данному программному продукту.
Требования к программному обеспечению по управлению проектами составляются исходя из уровня зрелости проектного управления, текущей ситуации с развитием ИТ в организации, объема проектной деятельности. При выборе основы для управления проектами рекомендуется проанализировать следующее:
• Внедрена ли на предприятии ERP-система? Если да, то есть смысл в первую очередь рассматривать модули по управлению проектами под внедренную ERP-платформу Если ERP-система не внедрена, то при выборе программного обеспечения логично ориентироваться на отдельные специализированные на автоматизации проектной деятельности программные продукты.
• Каковы требования к количеству рабочих мест в ИСУП? Какие группы пользователей будут работать в ИСУП? Помимо руководителей проектов и администраторов проектов в ИСУП могут быть выделены следующие роли с учетом ролевой модели, изложенной в методологии управления проектами: