Регламент по проектной деятельности в компании

1. Общие положения

Настоящий документ описывает общие положения и технологию ведения проектов Компании.

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

Документ содержит три основных раздела:

1. Общие принципы, закладываемые в положение и технологию;
2. Роли — Зоны ответственности, выделяемые в управлении проектами;
3. Стандарт управления проектом.

2. Общие принципы

2.1. Цели настоящего положения

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

1. Повышение прозрачности хода реализации проектов для руководителей и заинтересованных сотрудников компании;
2. Накопление и распространение опыта и знаний, получаемых в ходе реализации проекта от участников проекта другим сотрудникам компании;
3. Повышение качества выполняемых работ по проектам компании;
4. Адекватная оценка вклада каждого участника в результаты проектов;
5. Повышение производительности выполняемых работ, т. е. создание возможности для выполнения большего количества проектов;
6. Повышение экономической эффективности проектных работ;
7. Внедрение инструментов материального стимулирования, позволяющих повысить заинтересованность участников в успешной реализации проектов.

2.2. Границы применения настоящего положения

Область применения настоящего положения:

От начала выполнения проектов компании до завершения выполнения проектов компании.

В область применения не входят:

1. Принятие решений о необходимости и выполнении проектов;
2. Выбор руководителя и участников проекта;
3. Предпроектное исследование (разработка общего видения целей и задач проекта);
4. Разработка факторов риска и средств по борьбе с ними;
5. Оперативное управление решением задач проекта (в том числе координация работ с внешними группами).

Исходные сведения:

• Контрагент;
• Задача (предварительное понимание задачи);
• Назначенный руководитель проекта;
• Предварительный состав участников проекта.

Результирующие сведения:

• Завершенные работы;
• Подготовленная отчетная документация.

2.3. Модель управления проектами компании (критерии выбора решений)

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

1. Выделение только трех фаз проекта:

• Инициирование;
• Выполнение;
• Завершение.

2. Выделение четырех важнейших подсистем управления:

• Управление результатами;
• Управление временем и работами;
• Управление знаниями;
• Управление затратами.

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

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

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

В качестве экспертных идей настоящего положения предлагаются следующие:

1. Минимизация документов по ведению проектов;
2. Выделение главных инструментов в каждой из подсистем управления, а именно одна подсистема — один важнейший документ.

В основу реализации модели управления проектами заложены следующие ключевые тезисы:

1. Технологические особенности бизнеса компании;
2. Организационное разделение ответственности между задачами целеполагания и выполнения работ по достижению поставленных целей;
3. Одна подсистема управления — один главный инструмент (но не единственный);
4. Документирование значимых для реализации проекта событий и результатов;
5. Основные знания компании выражаются в следующем:
   • Порядок работ (внутренний план-график);
   • Шаблоны используемых документов по проекту;
   • Программно-технические наработки (конфигурации, настройки и т. п.).
6. Экспертный контроль реализации проектов.

3. Роли — зоны ответственности

Роли (зоны ответственности) описываются следующими понятиями:

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

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

Ответственность выражается в следующих формах:

1. Действия;
2. Принятие решений;
3. Утверждение — право высказывания мнения и влияние на принятие определенных решений;
4. Контроль — проверка соответствия результата определенным требованиям.

В настоящее время в компании выделяются следующие роли (представлены в виде краткого описания):

1. Руководитель компании
   Отвечает за утверждение ключевых событий по проекту (результатов проектов, сметы затрат). Управление отклонениями в реализации проектов (утверждение и принятие решений по нестандартным ситуациям);
2. Директор по качеству
   Отвечает за разработку и реализацию требований к системе управления проектами (в виде норм, положений, процедур, документов, методик, инструкций и стандартов, регламентирующих бизнес и поведение пользователя, норм корпоративной этики, правил поведения), соблюдение разработанных норм и аудит системы управления проектами;
3. Руководитель направления компании
   Отвечает за инициирование проектов, финансовые и стратегические результаты деятельности своего направления;
4. Менеджер проекта
   Отвечает за достижение выделяемых целей проекта, результативное и экономически эффективное использование ресурсов проекта (человеческих и материальных). Контролирует отклонения в реализации проектов;
5. Эксперт компании
   Отвечает за выбираемые методы и технологии, качество выполнения проектных работ специалистами соответствующей предметной области. Возможно, выделение одного и более экспертов проекта;
6. Специалист
   Отвечает за выполнение проектных работ и результатов (задач, поставленных менеджером проекта);
7. Менеджер по качеству
   Отвечает за контроль соблюдения требований нормативной документации компании.

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

4.1. Структура проектов

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

1. Внутренние проекты — цели лежат в области развития компании и направлений деятельности компании;
2. Внешние проекты — развитие (услуги для) клиентов компании.

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

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

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

1. Управление результатами;
2. Управление работами и временем;
3. Управление знаниями;
4. Управление затратами;
5. Управление качеством — техническая подсистема, включаемая для упорядочивания (контроля качества) ведения документов по проекту.

4.3. Принципы регламента

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

Главными инструментами являются следующие документы (см. рис):

1. Резюме проекта;
2. Спецификация результатов;
3. План-график;
4. Смета затрат;
5. Экспертиза проекта.

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

• Форма извещения об отклонении;
• Ответственное лицо за принятие решения по отклонениям;
• Схема передачи извещения об отклонениях;
• Сроки передачи извещения об отклонениях;
• Инициатор рассмотрения извещения об отклонениях;
• Форма рассмотрения извещения об отклонениях;
• Список ролевых участников рассмотрения извещения об отклонениях;
• Сроки принятия решения по отклонениям.

Отчетный документ рабочего совещания по отклонениям — Протокол совещания — хранится в папке «События, связанные с проектом».

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

• Ответственный;
• Требования к срокам выполнения;
• Наименование и статус исходящего документа.

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

Далее представлены характеристики каждой подсистемы управления проектом.

Подсистема Управление результатами

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

Основной инструмент подсистемы — спецификация результатов. Спецификация — это всестороннее описание результатов, которые соответствуют поставленным целям и обладают измеримостью.

1. Инициирование проекта
   При инициировании проекта формируется первоначальная спецификация.
   Основная задача — корректно сформулированный результат, актуальный до начала выполнения проекта.
   Также здесь формируется раздел, описывающий запланированные результаты этапов работы (формируется руководителем проекта);
2. Выполнение проекта
   Основная задача — актуализация спецификации, в т. ч. её расширение и изменение.
   Отражение факта достижения выделенных результатов, вклад каждого участника проекта;
3. Завершение проекта
   Основная задача — подведение итогов и выделение достижений команды и каждого участника проекта.

Подсистема Управление временем и работами

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

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

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

Ключевые параметры плана-графика:

1. Этап/Задача/ Работа;
2. Участник (и) (исполнитель и ответственный);
3. Дата, время плановое;
4. Дата, время фактическое;
5. Дата завершения работ (ориентировочная);
6. Причины отклонений.

1. Инициирование проекта
   В момент инициирования проекта формируется нормативный план-график.
   Основная задача — получение максимально подробно прописанной иерархии работ;
2. Выполнение проекта
   Основная задача — отражение задач проекта в конкретизированные планы работ участников проекта, ведение учета фактически затраченного времени. Отражение причин отклонений;
3. Завершение проекта
   Основная задача — подведение итогов и систематизация причин возникших отклонений.

Подсистема Управление затратами

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

1. Инициирование проекта
   Формируется плановая смета затрат.
   Основная задача — адекватная прогнозная оценка затрат, связанных с реализацией проекта;
2. Выполнение проекта
   Отражение факта понесенных затрат, расширение плановой части сметы;
3. Завершение проекта
   Подведение финансовых итогов проекта. Формирование результирующего отчета.

Подсистема Управление знаниями

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

Основной инструмент подсистемы:

1. Инструменты предыдущих подсистем;
2. Используемые документы (рабочие и отчетные);
3. Используемые программно-аппаратные средства (ПАС);
4. Документ — Экспертиза проекта.

1. Инициирование проекта
   Формируется перечень используемых документов и ПАС, ссылки на проекты, инструменты которых можно взять за основу разработки нормативных.
   Также формируется документ экспертиза проекта с выделением событий, которые надо «экспертировать».
   Форма для документов и ПАС: Наименование, Назначение, Есть ли в наличии — где.
   Форма для инструментов: Перечень проектов, контактных лиц;
2. Выполнение проекта
   Для утверждения каждого этапа проекта привлекается эксперт (эксперты).
   Основная задача — анализ решений и результатов этапа до его завершения и отражение результатов экспертного анализа в документе Экспертиза проекта. Рекомендации экспертизы — являются обязательными для исполнения в проекте.
   События, которые необходимо экспертировать, определяются на этапе инициирования проекта;
3. Завершение проекта
   Сбор и обобщение материалов, размещение их на хранение.
   Подготовка Резюмирующего раздела документа экспертиза проекта.

Подсистема Управления качеством

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

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

1. Проектной документации, описанной выше;
2. Формальной документации, связанной с реализацией проекта (подробно рассматривается в регламенте ведения документации).

Основные инструменты:

1. Документ — Резюме проекта;
2. Регламент ведения документации.

5. Регламент ведения документации

5.1. Управление результатами

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

Регламентные действия

Действия	Ответственный	Требования к срокам	Документ	Статус документа
Инициирование проекта
Подготовить резюме проекта	Руководитель направления	После принятия решения	Резюме проекта	На согласование
Довести до сведения руководителя компании	Руководитель направления	В течение часа после завершения подготовки документа	Резюме проекта	Согласован
Подготовить спецификацию результатов проекта	Руководитель направления	В течение дня после получения резюме проекта	Спецификация результатов	На утверждение
Подготовить спецификацию результатов этапов проекта	Менеджер проекта	В течение дня после получения резюме проекта	Спецификация результатов	На утверждение
Утверждение спецификации результатов	Руководитель направления	В течение часа после получения	Спецификация результатов	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение часа после получения	Спецификация результатов, резюме проекта	Согласован
Утверждение спецификации результатов	Руководитель компании	После получения, по мере возможности	Спецификация результатов, резюме проекта	Утвержден
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после получения	Спецификация результатов, резюме проекта	Результирующий
Выполнение проекта
Внесение сведений о поэтапных вкладах и достижениях запланированных результатов	Менеджер проекта	На усмотрение менеджера (не реже 1 раза в неделю).	Спецификация результатов	Актуальный
Внесение сведений о вкладе и достижениях каждого участника проекта	Менеджер проекта	На усмотрение менеджера (не реже 1 раза в неделю).	Спецификация результатов	Актуальный
Завершение проекта
Подготовка раздела отчета, связанного с достижением/ не достижением целей проекта	Руководитель направления	В течение недели после завершения проекта, если не оговорена срочность исполнения	Спецификация результатов	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение часа после получения	Спецификация результатов	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки соблюдения требований к нормативной документации	Спецификация результатов	Результирующий

Отклонения

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

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

5.2. Управление работами и временем

Регламентные действия

Действия	Ответственный	Требования к срокам	Документ	Статус документа
Инициирование проекта
Разработка внутреннего плана-графика работ	Менеджер проекта	После подготовки спецификации результатов	Внутренний план-график	На рассмотрение
Рассмотрение внутреннего плана-графика, внесение корректив и замечаний	Руководитель направления	В течение дня после получения документа	Внутренний план-график	Рассмотрен
Передача рассмотренного внутреннего плана-графика на доработку менеджеру проекта	Руководитель направления	По завершении рассмотрения внутреннего плана-графика	Внутренний план-график	Рассмотрен
Разработка плана загрузки ресурсов проекта на основе формы внутреннего плана-графика	Менеджер проекта	После получения внутреннего плана-графика с замечаниями	Внутренний план-график	Актуальный
Передача внутреннего плана-графика работ на экспертизу	Менеджер проекта	По завершении разработки	Внутренний план-график	На экспертизу
Экспертиза внутреннего плана-графика работ	Эксперт	В течение дня после получения	Внутренний план-график	Согласован
Передача внутреннего плана-графика работ на утверждение руководителю направления	Эксперт	По завершении экспертизы	Внутренний план-график	На утверждение
Утверждение внутреннего плана-графика	Руководитель направления	В течение часа после получения документа	Внутренний план-график	Утвержден
Передача документа на контроль качества документации	Руководитель направления	В течение часа после получения утвержденного документа	Внутренний план-график	Утвержден
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение часа после получения	Внутренний план-график	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки	Внутренний план-график	Результирующий
Выполнение проекта
Формирование еженедельного плана работ по каждому участнику проекта	Менеджер проекта	Не позднее 17:30 пятницы предыдущей недели	Внутренний план-график	Актуальный
Отражение фактического выполнения плана	Менеджер проекта	До 17:30 пятницы отчетной недели	Внутренний план-график	Актуальный
Завершение проекта
Завершающая обработка внутреннего плана-графика	Руководитель направления	В течение недели после завершения проекта, если не оговорена срочность исполнения	Внутренний план-график	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение двух часов после получения	Внутренний план-график	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки соблюдения требований к нормативной документации	Внутренний план-график	Результирующий

Отклонения

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

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

5.3. Управление затратами

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

Регламентные действия

Действия	Ответственный	Требования к срокам	Документ	Статус документа
Инициирование проекта
Подготовка плановой сметы затрат	Руководитель направления	После подготовки плана-графика	Плановая смета затрат	На согласование, ДСП
Уточнение плановой сметы затрат	Менеджер проекта	В течение двух часов после получения	Плановая смета затрат	На согласование, ДСП
Передача плановой сметы затрат на утверждение Руководителю компании	Руководитель направления	После уточнения сметы затрат менеджером проекта	Плановая смета затрат	На утверждение, ДСП
Утверждение плановой сметы затрат	Руководитель компании	По мере возможности	Утвержденная плановая смета затрат	Утвержден, ДСП
Выполнение проекта
Формирование отчетной части. Внесение корректив в смету.	Менеджер проекта	До 17:30 пятницы отчетной недели	Смета затрат	Актуальный, ДСП
Завершение проекта
Завершающая обработка документа	Менеджер проекта	В течение недели после завершения проекта	Смета затрат	Актуальный, ДСП
Довести до сведения руководителя направления	Менеджер проекта	В течение часа после завершения обработки документа	Смета затрат	На согласование, ДСП
Экспертиза сметы затрат	Руководитель направления	В течение 2-х часов после получения	Смета затрат	Согласован, ДСП
Передача проверенной сметы затрат на утверждение Руководителю компании	Руководитель направления	По окончании экспертизы	Смета затрат	На утверждение, ДСП
Подведение итогов	Руководитель компании	По мере возможности	Смета затрат	Утвержден, ДСП

Отклонения

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

1. Руководитель направления;
2. Руководитель компании;
3. Менеджер проекта.

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

5.4. Управление знаниями

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

Регламентные действия

Действия	Ответственный	Требования к срокам	Документ	Статус документа
Инициирование проекта
Подготовить перечень используемых документов и ПАС, ссылки на проекты, инструменты которых можно взять за основу разработки нормативных	Руководитель направления	После утверждения плана-графика работ	Перечень используемых документов и ПАС	На согласование
Довести до сведения руководителя компании	Руководитель направления	После завершения подготовки перечня	Перечень используемых документов и ПАС	На согласование
Подготовка перечня событий, подлежащих экспертизе, для формирования документа экспертиза проекта	Руководитель направления	После согласования перечня используемых документов и ПАС	Экспертиза проекта	Актуальный
Передача экспертизы проекта на контроль менеджеру по качеству	Руководитель направления	После завершения подготовки экспертизы проекта	Экспертиза проекта	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение двух часов после получения	Экспертиза проекта	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки соблюдения требований к нормативной документации	Экспертиза проекта	Результирующий
Выполнение проекта
Подготовка рекомендаций экспертов по каждому этапу проекта, в соответствии с планом работ	Эксперт (ы)	В течение дня после получения материалов	Экспертиза проекта (с внесенными изменениями)	Актуальный
Передача подготовленных рекомендаций менеджеру проекта для ознакомления и обсуждения	Эксперт (ы)	После завершения подготовки рекомендаций	Экспертиза проекта (с внесенными изменениями)	На согласование
Анализ решений и результатов экспертного анализа и отражение в экспертизе проекта	Менеджер проекта	По мере необходимости	Экспертиза проекта	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение двух часов после получения	Экспертиза проекта	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки соблюдения требований к нормативной документации	Экспертиза проекта	Результирующий
Завершение проекта
Сбор и обобщение материалов, передача руководителю направления	Менеджер проекта	В течение недели по окончании проекта		На согласование
Подготовка Резюмирующего раздела документа экспертиза проекта	Руководитель направления	В течение недели по окончании проекта	Экспертиза проекта	Актуальный
Передача экспертизы проекта на экспертизу	Руководитель направления	В течение часа после завершения подготовки документа	Экспертиза проекта	На экспертизу
Дополнение резюмирующего раздела экспертизы проекта экспертным мнением	Эксперт (ы)	В течение трех дней после получения материалов	Экспертиза проекта, дополненная мнением экспертов	Актуальный
Передача экспертизы проекта менеджеру по качеству	Эксперт (ы)	После корректировки экспертизы проекта	Экспертиза проекта, дополненная мнением экспертов	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение одного дня после получения	Экспертиза проекта, дополненная мнением экспертов	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение одного дня после получения	Экспертиза проекта, дополненная мнением экспертов	Результирующий

Отклонения

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

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

5.5. Управление качеством

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

Регламентные действия

Действия	Ответственный	Требования к срокам	Документ	Статус документа
Инициирование проекта
Актуализация требований по ведению проектной и формальной документации, связанной с реализацией проекта	Директор по качеству	По мере необходимости	СТП	Актуальный
Корректировка Регламента ведения документации в соответствии с установленными требованиями,	Менеджер по качеству	В течение дня после получения изменений требований по ведению документации	Регламент ведения документации	Актуальный
Передача актуализированного Регламента ведения документации на согласование Директору по качеству	Менеджер по качеству	После завершения корректировки Регламента ведения документации	Регламент ведения документации	На согласование
Ознакомление с Регламентом ведения документации	Директор по качеству	В течение дня после получения Регламента ведения документации	Регламент ведения документации	Согласован
Формирование (актуализация) балльной шкалы оценок регламентных действий	Директор по качеству	В течение дня после получения	Регламент ведения документации	На утверждение
Утверждение балльной шкалы оценок	Руководитель компании	По мере возможности	Регламент ведения документации	Утвержден
Размещение актуализированных документов	Менеджер по качеству	В течение 2-х часов после получения	Комплект подготовленных документов	Результирующий
Выполнение проекта
Контроль соблюдения требований к нормативной документации компании, заполнение журнала несоответствий	Менеджер по качеству	По мере поступления документов на контроль	Журнал несоответствий проектной документации, часть 1	Актуальный
Текущий анализ несоответствий	Директор по качеству	До 17:30 пятницы отчетной недели	Журнал несоответствий проектной документации, часть 1	Актуальный
Завершение проекта
Итоговый анализ качества ведения проектной документации и эффективности информационного обмена в рамках проекта	Директор по качеству	В течение недели после завершения проекта	Журнал несоответствий (заполнена часть 2)	Результирующий

Отклонения

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

1. Директор по качеству;
2. Менеджер по качеству.

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

Февраль 2005 г.

Рекомендуемые материалы по тематике

Описание и оптимизация бизнес-процессов с минимальными инвестициями и рисками

Применение системы Business Studio в Офисе управления проектами

Business Studio 3.0: Делаем компанию эффективной

Процессные команды как основа культуры эффективности

В статье разберем особенности проектного управления на предприятии. Разъясним, какую задачу считать проектом, из каких этапов он состоит, какие инструменты позволят эффективно им управлять.

Что считается проектом

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

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

Рисунок 1. Условия выделения группы задач в проект

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

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

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

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

Инструментарий управления проектами

Управление проектами – это деятельность, в ходе которой определяются и достигаются цели проекта, при этом соблюдается баланс между объемом работ, ресурсами, временем, качеством и рисками. Наиболее популярными подходами к управлению проектами являются:

• PMI;
• PRINCE2;
• SDLC;
• Agile;
• Extreme;
• Lean Six Sigma;

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

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

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

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

Основные этапы проекта

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

Можно выделить группы процессов, которые свойственны каждому проекту (см. рисунок 2).

Рисунок 2. Группы процессов проекта

Далее рассмотрим их подробнее.

Инициирование проекта

Инициирование проекта можно разделить на две части:

1. Формирование устава проекта.
2. Формирование команды проекта.

Устав проекта – это относительно небольшой по объему документ (6–7 слайдов максимум). Напомню, что мы говорим о внутренних проектах, где исполнитель и заказчик работают в одной компании. Устав проекта преследует следующие цели:

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

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

Наименование проекта: Улучшение процесса обслуживания покупателей
Предпосылки: покупатели выражают недовольство длительным сроком или отсутствием ответов на свои запросы	Участники проекта: Спонсор проекта: Заказчик проекта: Куратор проекта: Руководитель проекта: Команда проекта:
Цели: Обеспечить ответ на каждый запрос. Сократить средний срок решения запроса покупателя на 60%. Сократить количество повторных обращений на 80%	Критерии оценки: Среднее время реагирования на запрос покупателя. Количество повторных запросов. Результаты ежегодного опроса покупателей
Периметр проекта: подразделение Южного-Федерального округа	Допущения: Документация проекта будет рассмотрена не позднее20 декабря 2019 г. Проектная команда будет утверждена в предложенном составе
Ключевые вехи: Утверждение проекта – январь 2020 г.
Анализ и протоколирование источников – февраль 2020 г.
Утверждение рекомендаций – апрель 2020 г.
Внедрение рекомендаций – май 2020 г.

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

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

Планирование проекта

Этап должен ответить на следующие вопросы:

1. Что планируется сделать?
2. Как планируется сделать?
3. Какие события являются критериями завершения проекта?

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

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

Рисунок 3. Структура плана проекта

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

Два других раздела итогового плана, о которых стоит упомянуть отдельно – это финансовая модель и план мероприятий. Приведем несколько основных тезисов, обязательных при формировании этих разделов.

1. Финансовый план и план мероприятий должны быть синхронизированы.
2. Финансовый план должен рассчитывать объем необходимых инвестиций и бюджеты проекта. Бюджеты могут быть разбиты по времени и подразделениям, но в сумме они должны быть сопоставимы с объемом запрошенных инвестиций.
3. Финансовый план должен учитывать именно те ресурсы, которые будут предоставлены для его реализации. Из этого тезиса, например, возникает необходимость разделения учета расходов на персонал на операционную деятельность и непосредственно на реализацию проекта.
4. Оба плана должны допускать возможность внесения изменений в рамках утвержденных процессов.
5. Финансовый план и бюджет проекта должны быть синхронизированы с текущей учетной политикой компании. Неэффективно планировать расходы и доходы без возможности последующего сбора соответствующих фактических значений.

Планирование проекта – это сложный и порой дорогостоящий процесс. Самое важное на этом этапе понять два ключевых момента:

1. Степень обоснованности доходной части проекта (если речь идет о проектах с запланированной отдачей на вложенный капитал). Недоработки в этой части были и остаются основной причиной неудач проекта.
2. Способы управления рисками проекта. То, как команда проекта планирует управлять рисками, определит величину потенциальных убытков.

Проектные задачи – это всегда умение работать с неопределенностью.

Исполнение проекта

Из всего, что важно для успешного исполнения задач проекта, можно подчеркнуть следующее:

1. Необходимо защищать периметр проекта. Желание расширить его границы возникает практически всегда. И здесь важно донести до заказчика и спонсора необходимость внесения соответствующих изменений в утвержденные планы или о воздержании от внесения таковых.
2. Основная роль руководителя проекта – это коммуникации. Важно ограничивать свое желание уйти в исполнение, разработку продукта, проектирование и т.п. Коммуникации на предприятии могут стать настоящим кошмаром проектного управления, если им не уделять большую часть своего внимания.
3. Согласованные в проектной документации ресурсы должны быть реально предоставлены.
4. Мотивация персонала для проектных и операционных задач должна быть разной. Проектные задачи – это всегда умение работать с неопределенностью. Здесь важно избегать формальных решений, и отдельная мотивация является одним из наиболее эффективных инструментов. Она может быть выражена в виде премий, доли в проекте и в виде любых других поощрений.

Мониторинг и контроль проекта

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

Рисунок 4. Иерархия проектов

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

Закрытие проекта

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

Рисунок 5. Варианты закрытия проекта

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

Заключение

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

Безусловным минусом внедрения проектного менеджмента в компании являются дополнительные расходы и бюрократизация процессов. В малых масштабах оно не окупается.

Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

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

Жизненный цикл проекта

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

Например, PMBok приводит схему жизненного цикла так:

То есть все очень просто – опишите жизненный цикл.

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

Уровни управления и уровни методологии

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

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

О каких же документах идет речь? Основных действий, которые необходимо описать, и основных документов не так уж и много:

Пример визуализации плана КТ в системе ADVANTA

Пример отчета о статусе проекта в системе ADVANTA

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

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

Но и это не гарантия большой сложности исполнения.

Дополнительно по теме: Что нужно знать, начиная проект, чтобы избежать провала? 

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

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

Все эти вопросы приводят к необходимости создания методики определения типов проектов. Я назвала такой документ «методикой определения сложности».

Методика определения сложности проектов

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

Пример системы критериев, их оценок и весов:

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

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

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

Как упростить управление: пример из жизни

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

• Проекты
• Стратегические инициативы
• Проекты описания бизнес-процессов

Пример оценки проектов по уровню сложности, используемой в компании «Адванта Консалтинг»

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

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

Когда термин «проект» был определен, подготовка регламента управления проектами компании не составила большого труда, мне оставалось просто собрать требования к поддержке жизненного цикла двух типов активностей. Определение жизненного цикла для действительного «ПРОЕКТА» – то, что нужно для старта методологии. Такая работа расставит все точки над «i»: определит, чем вы будете руководить, как вы это будете делать и какие документы использовать. 

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

Дополнительно по теме: Что первично: методология или ИСУП?