www. ibs. ru Часть 3. Корпоративный стандарт управления проектами
План занятий (Часть 3) Тема Время Раздел 7. Структура и содержание стандарта управления проектами 7. 1. Основные принципы создания стандарта: специализация и детализация 7. 2. План управления проектами и Классификация проектов 7. 3. Процедурная составляющая стандарта 2 часа Раздел 8. Организационные структуры в проектах 8. 1. Управление проектом и административное управление 8. 2. Команда проекта 8. 3. Команда управления проектом 8. 4. Квалификационные требования к персоналу проекта 8. 5. Международная сертификация специалистов по управлению проектами 2 часа Мастерская 2. Проектный учет и отчетность 4 часа Раздел 9. Базовые элементы стандарта 9. 1. Управление предметной областью (содержанием и границами) проекта 9. 2. Управление по временным параметрам 2 часа Раздел 10. Управление стоимостью и финансами в проектах 10. 1. Процедуры управления стоимостью 10. 2. Оценки, смета, бюджет, финансовые потоки 10. 3. Финансовая структура проекта 10. 4. Показатели освоенного объема 2 часа 2
План занятий (Часть 3) Тема Раздел 11. Проектные отклонения Время 2 часа 11. 1. Управление рисками 11. 2. Управление проблемами 11. 3. Управление изменениями Мастерская 3. Определение исходных рисков проекта 4 часа Раздел 12. Другие разделы корпоративного стандарта 2 часа 12. 1. Управление поставками и контрактами 12. 2. Управление коммуникациями 12. 3. Обеспечение охраны труда и промышленная безопасность 12. 4. Обеспечение охраны окружающей среды 12. 5. Обеспечение работы с претензиями 12. 6. Управление качеством в проекте 3
Корпоративный стандарт управления проектами Раздел 7. Структура и содержание стандарта управления проектами 7. 1. Основные принципы создания стандарта: специализация и детализация 7. 2. План управления проектами и Классификация проектов 7. 3. Процедурная составляющая стандарта 5
Управление проектами в компании – процедуры и документы Руководство Компании Команда проекта Account manager Project manager Служба администрирования проектов Системный архитектор Принятие решения о начале проекта Определение потребности в проекте Обоснование открытия проекта Принятие решения о назначении PM Решение об открытии проекта Заявка на Project Manager’а Назначение Project Manager’а Определение проекта Формирование заявки на регистрацию проекта Технологичес. Служба кие подразавтоматизации деления Заявка на Системного архитектора Назначение Системного архитектора Project Manager, Системный архитектор Заявка на регистрацию проекта Регистрация проекта Детализация требований Заказчика Устав проекта Служба управления проектами Уведомление о назначении Project Manager’а Номер проекта Определение персонального состава команды проекта Заявка на управленческий персонал Заявка на технический персонал Оформление заявок на персонал Выделение ресурсов Решение о привлечении дополнительног о персонала Формирование положения о рабочей группе Положение о рабочей группе Выделение ресурсов Управленческий и технический персонал Заявка на установку оборудования, программ, на выделение информационного пространства Определение инфраструктуры проекта План работ, ресурсов, первичный бюджет Оборудование, программы, информационное пространство План работ Планирование маркетинговой стадии проекта Формирование инфраструктуры проекта Первичное планирование План финансирования работ Уточнение требований Заказчика Решение о привлечении субподрядчиков Положительное заключение Предварительный выбор субподрядчиков Уточненные требования Заказчика Замечания к контракту Контроль хода работ ТКМ Утверждение контракта Стоимость, длительность и трудозатраты по работам Предварительный технический план, план-график, ресурсный план, предварительный бюджет Мониторинг проекта Формирование проектов планов и бюджета Проект контракта Контракт Подготовка контракта Утвержденный контракт Закрытие маркетинговой стадии Отчет о проекте Освобождение из проекта PM и СА Исполнение работ Технический план, план-график, ресурсный план, предварительный бюджет Согласование контракта с Заказчиком Утвержденный контракт Оценка работ Технико-коммерческие материалы Формирование проектов планов, содержательной части контракта и бюджета коммерческой стадии Определение цены продажи Согласованный контракт Техническое руководство Организация технической экспертизы ТКМ Согласование ТКМ с Заказчиком Замечания к контракту Список субподрядчиков Определение содержания, оценка стоимости и сроков выполнения работ коммерческой стадии Мониторинг проекта Технический отчет Сводный отчет о маркетинговой стадии Регистрация контракта Административное закрытие Сообщение о закрытии маркетинговой стадии Освобождение ресурсов Аудит проекта 6
Принципы построения стандарта Специализация Инициация Инициализация Планирование Организация Выполнение выполнения и контроль Контроль Анализ и регулирование Закрытие Удалениесистемы Сопровождение Внедрение обучение , Реализация Проектирование Техническоезадание Риски Персонал Коммуникации Контракты Изменения Концепция ● включение в стандарт предприятия тех и только тех положений, которые имеют отношение к проектной деятельности именно на этом предприятии и в привязке к реалиям этого предприятия Функции управления Содержаниеи границы Время Стоимость Качество Стадии жизненного Фазы цикла проекта Стадии управления Фазы управления Детализация ● степень подробности объяснений или предписаний как, в какой последовательности, в какие сроки, с использованием каких шаблонов нужно выполнять те или иные действия в процессе управления проектами 7
Политика компании по управлению проектами Политика управления проектами основополагающий (короткий) документ, определяющий принципы управления проектами в компании и разграничивающий сферы ответственности различных подразделений и отдельных должностных лиц компании при осуществлении деятельности, реализуемой в проектной форме. Основные составляющие Политики управления проектами – ● классификация проектов ● жизненные циклы проектов ● функциональные роли и ответственность участников проектов ● организационные структуры в проектах ● укрупненные схемы (регламенты) взаимодействия участников в рамках основных процессов управления проектами 8
План управления проектом – «Устав проекта» Устав проекта (Project Charter): Что включать в Устав проекта: ● ● Содержание ● Документ, выпущенный вышестоящей администрацией и предоставляющий менеджеру проекта полномочия привлекать ресурсы организации для выполнения работ проекта Документ, фиксирующий общее понимание проекта Заказчиком и Исполнителем Как сформировать Устав проекта: ● Время – стадия инициализации проекта ● Цель – зафиксировать общее понимание и взаимные обязательства ● Метод – Workshop (мастерская) ● Участники – ключевые представители Заказчика и Исполнителя Можно ли сформировать типовой Устав проекта, как элемент корпоративного стандарта управления проектами? стратегические достижения и границы цели, проекта результаты, - критерии ● Ключевые вехи - основные промежуточные результаты и время их достижения ● Организационная структура – команда проекта, команда управления проектом ● Плановый бюджет – смета затрат, финансовые резервы, финансовые потоки ● Предположения и ограничения – внешние факторы, находящиеся вне прямого влияния команды проекта, которые могут повлиять на выполнения работ ● Требования и стандарты – перечень государственных, отраслевых или корпоративных стандартов, используемых в проекте ● Проектная документация – содержательные документы, способы их хранения и распространения ● Управление отклонениями – начальные риски, процедуры работы изменениями с рисками, проблемами, ● Обеспечение качества – методы контроля качества результатов работ ● Контроль и отчетность – документы и процедуры управленческой отчетности по проекту 9
Классификация проектов По направлению деятельности ● ИТ проекты ● Строительство, реконструкция и капитальный ремонт (строительные проекты) ● Проекты обучения По источникам финансирования - ● Инвестиционные проекты (капитальное строительство) ● Проекты НИОКР ● Проекты, реализуемые за счет издержек на производство По используемым ресурсам - Классификация по масштабности проекта ● Территориальная разбросанность, стоимость Классификация по форме учета и оплаты ● Fixed price, Time & Materials Классификация по сложности (комплексности) проекта ● Обычные проекта (Ba. U), стандартные проекты системной интеграции, сложные проекты системной интеграции ● Внутренние ● Внешние ● Смешанные 10
Классификация проектов строительной компании Масштабность проекта Стоимость Низкая стоимость Средняя стоимость Высокая стоимость Низкая продолжительность Малый Средний Средняя продолжительность Малый Средний Крупный Большая продолжительность Средний Крупный Длительность Сложность проекта Новизна Заинтересованные Одна или две От трех до пяти Более пяти стороны заинтересованные заинтересованных стороны Стандартное решение Низкая сложность Средняя сложность Модернизированное решение Низкая сложность Средняя сложность Известное на рынке решение Средняя сложность Высокая сложность Новое решение Средняя сложность Высокая сложность 11
От классификации проектов к Уставу проекта План управления проектом По Форме учета и оплаты работ По масштабности проекта Шаблон Плана (макрошаблон) получается как простая сбора микрошаблонов По предметной области проекта Классификация проектов Содержание и границы проекта Ключевые вехи проекта Плановый бюджет проекта Требования и стандарты Организационная структура Управление документацией Управление отклонениями Обеспечение качества Контроль и отчетность 12
Специализированный микрошаблон раздела "Содержание и границы" Рекомендация рамочного стандарта (для любого проекта) Содержание специализированного шаблона для проектов создания ИТ-инфраструктуры филиала банка Обоснование проекта (Project justification) Описываются основные характеристики продукта и их взаимосвязь с деловой необходимостью или иными стимулами. Во всех филиалах должна быть установлена унифицированная, надежная, гибкая и легко наращиваемая ИТ-инфраструктура на основе платформы XXXXX, позволяющая использовать в качестве основного средства обработки бизнес транзакций прикладного программного обеспечения YYYYY. Продукт проекта (Project product) Основные характеристики продукта и их взаимосвязи, необходимые для целостной (интегральной) приёмки продукта Доставить, установить и настроить оборудование и системное программное обеспечение во вновь создаваемый филиал банка, формирующее основу для последующего внедрения банковской информационной системы. Результаты проекта (Project deliverables) Приводится перечень результатов (подпродуктов), достижение (полное и успешное создание) которых означает завершение проекта Спецификации системного программного обеспечения и его конфигурация Требования к помещению для установки оборудования Перечень оборудования и программного обеспечения План технического решения Эталонные копии установки и конфигурации системного программного обеспечения Оборудование и системное программное обеспечение, доставленное в филиал банка, установленное и подготовленное для установки банковской информационной системы. Критерии оценки результатов (Project objectives) Описание количественных критериев, которые должны быть удовлетворены, чтобы проект считался успешным Срок доставки оборудования и программного обеспечения в Москву не должен превышать ХХ дней. Срок наладки оборудования и программного обеспечения в Москве не должен превышать YY дней. Срок транспортировки оборудования и программного обеспечения в филиал банка не должен превышать ZZ дней. Срок установки и наладки оборудования и программного обеспечения в филиале не должен превышать WW дней. Пункт микрошаблона 13
Пространство процессов управления проектами Функции управления Содержание и границы Инициация Планирование Выполнение Удаление системы Сопровождение Контракты Изменения Внедрение, обучение Коммуникации Концепция Персонал Реализация Риски Проектирование Качество Техническое задание Время Стоимость Стадии жизненного цикла проекта Контроль Закрытие Фазы управления 14
Процессы управления проектами «Горизонтальные» процедуры: этапы жизненного цикла Этап ЖЦП Стадия управления Функция управления Управление временем Управление стоимостью Определение общих сроков разработки ТЗ Планирование Формирование и Определение и согласование с согласование исполнителями стоимостей детального детализированных календарного плана работ ТЗ (в том работ этапа числе работ соисполнителей) Организация выполнения и контроль Контроль сроков исполнения работ Анализ и регулирование Техническое задание Инициализация Управление качеством Формирование и согласование планов контроля качества работ Определение команды разработки ТЗ (состав рабочей группы) Управление коммуникациями Управление контрактами Сбор и анализ Определение необходимой перечня исходной контрактной информации, документации - анализ регламентов договоров, актов и взаимодействия т. д. Управление изменениями Разработка стратегии создания ТЗ и вариантов реагирования на возможные изменения Согласование детального сроков, форм и календарного плана способов передачи разработки ТЗ по информации и ресурсам представления исполнителей результатов Определение и согласование, шаблонов контрактной документации закрытия этапа ТЗ Определение границ допустимых отклонений по видам ресурсов и промежуточных результатов Учет реальной Внутреннее стоимости (затрат) согласование выполненных работ варианта ТЗ всеми Изменение статуса исполнителями работ этапа Координация работ команды этапа проекта. Оформление документов проектного учета Предоставление необходимой исходной информации для разработки ТЗ исполнителям Внутреннее подписание (визирование) варианта ТЗ всеми исполнителями подэтапов. Формирование информационных отчетов о ходе выполнения детального календарного плана Сравнение директивного графика и реального состояния статусов работ Получение отчетности и контроль привлечения ресурсов (в том числе и по соисполнителям) Рассылка копий ТЗ Принятие решения Анализ и контроль "внешним" о доработках и изменений в Экспертам согласование процессе возможных получения версий Принятие решения изменений условий (вариантов) ТЗ и отправка контрактов с Согласование заключительного субподрядчиками и изменений с варианта ТЗ представителями Заказчиком Заказчику Заказчика Инициация необходимых изменений в календарных планах Закрытие Определение бюджета этапа ТЗ нормативных (в том числе, работ документов соисполнителей) Управление персоналом Сравнение Организация реальной "внешней" стоимости (затрат) экспертизы выполненных работ Принятие решения с плановой о доработках ТЗ стоимостью или отправке его Заказчику Формирование акта Формирование Согласование и Закрытие завершения работ счета к оплате подписание ТЗ (подписание этапа ТЗ завершенных работ Timesheet) Принятие решения Закрытие этапа ТЗ о создании архивной копии Создание архивной Утверждение копии результатов Заказчиком и закрытие этапа ТЗ Примечание: Управление содержанием и границами этапа осталось «за кадром» Согласование и подписание ТЗ с заказчиком (с учетом фиксации возможных изменений) 15
Процессы управления проектами «Вертикальные» процедуры: время, стоимость, риски, персонал. . . Стадия управления Функция управления Управление по временным Управление по стоимостным параметрам Инициация Определение временных рамок проекта Планирование Формирование общего календарного плана проекта Выбор субподрядчиков Формирование детального плана этапа Организация выполнения и контроль Учет затрат рабочего времени по работам этапа Изменение статуса работ этапа Учет реальной стоимости выполненных работ Анализ и регулирование Сравнение директивного графика работ этапа и реального состояния статусов работ этапа Инициация необходимых изменений в календарных планах Сравнение директивных и реальных стоимостей работ этапа Инициация необходимых изменений в бюджете проекта Закрытие Формирование акта завершения работ этапа Завершение проекта Формирование счета по завершенным работам Определение бюджета проекта Определение стоимостей этапов работ Определение стоимостей детализированных работ 16
Процессы управления проектами «Вертикальные» процедуры: Содержание, время, стоимость, персонал. . . 17
Типовые документы управления проектами (примеры) Процедуры Управленческие документы ● Принятие решений о запуске проектов ● Устав проекта ● Выбор подрядчика и заключение контракта ● Отчет о статусе проекта ● Запуск проекта ● Контроль и отчетность ● Управление отклонениями ● Закрытие проекта Рабочие инструкции ● Контроль проекта по методу освоенного объема ● Календарно-ресурсный план ● Журнал отклонений и т. д. ● Исполнительные (по завершению проекта) документы Должностные и ролевые инструкции ● Инструкция Директора проекта ● Инструкция Руководителя проекта ● Инструкция Администратора проекта и т. д. 18
Структура документации Стандарта управления проектами Процедура Пр. 33 Управление проектами Рабочая инструкция Ри. 51 Планирование бюджета коммерческого проекта Рабочая инструкция Ри. 56 Ри. 55 Формирование организационной структуры проекта Форма Рабочая инструкция Ри. 59 Рабочая инструкция Ри. 58 Планирование коммерческого проекта Управление рисками Рабочая инструкция Ри. 57 Управление проблемами Управление изменениями Рабочая инструкция Ри. 61 Формирование отчетности по проекту Рабочая инструкция Контроль исполнения бюджета. Форма Внутренняя спецификация Определение проекта Рабочая инструкция Ри. 60 Ф. 63_01 План управления проектом Форма Ф. 63_02 Протокол стартового совещания по проекту Форма Ф. 23_01 Форма План-график работ по проекту Ф. 58_01 Карта риска Ф. 60_01 Карта проблемы (Календарный план проекта и Ресурсный план проекта в MS Project ) Форма Ф. 57_01 Журнал рисков Ф. 59_01 Журнал проблем Форма Ф. 62_01 Карта запроса на изменение Форма Ф. 61_01 Журнал изменений Форма Ф. 27_01 Отчет о состоянии проекта Форма Отчет по бюджету проекта (из R 3) Форма Ф. 26_01 Протокол совещания Форма Ф. 27_01_2 Создание и сопровождение папки проекта Ф. 29_01 Отчет о состоянии проекта поставки Рабочая инструкция Ри. 52 Отчет о выполненном проекте 19
Корпоративный стандарт управления проектами Раздел 8. Организационные структуры в проектах 8. 1. Управление проектом и административное управление 8. 2. Команда проекта 8. 3. Команда управления проектом 8. 4. Квалификационные требования к персоналу проекта 8. 5. Международная сертификация специалистов по управлению проектами 20
Баланс интересов в проектно-ориентированной компании Владелец ресурсов: Руководитель проекта: ● «продать» всех и подороже ● «купить» лучших и подешевле Взаимоотношения владельца ресурсов и руководителя проектов регулируются системой регламентов и нормативов: ● Сколько стоит специалист, ● Как получить специалиста в проект, ● Как не дать специалиста в проект, ● Как отказаться от специалиста… 21
Разделение ответственности при административном и проектном управлении Сфера ответственности Область управления Ответственность начальника подразделения (административное управление) Ответственность руководителя проекта (управление проектами) Планирование и контроль ● Формирование бизнес-плана отдела ● Планирование бюджета отдела ● Контроль “по вехам” ● Отчетность перед руководством предприятия Человеческие ресурсы ● Прием на работу и увольнение ● Формирование команды проекта ● Централизованное выделение ● Анализ и оценка работы ресурсов сотрудников ● Контроль дисциплины ● Регулирование конфликтов внутри проекта ● Организация обучения ● Применение санкций и поощрений ● Регулирование конфликтов внутри подразделения Реализуемые продукты ● Методология создания ИС (на примере ● Инструментарий разработки ИС информационных ● Авторский надзор систем) ● Детальный календарный план проекта ● Планирование бюджета проекта ● Оперативный контроль хода проекта ● Отчетность перед руководством ● Проектирование ИС ● Разработка ИС ● Внедрение ИС 22
Контрактная модель проекта по Родни Тернеру 23
Процедура формирования команды проекта Заявка на персонал проекта Уведомление о выделении персонала (зарегистрированное) Руководитель проекта Пользовательские интерфейсы Календарный план проекта Система календарноресурсного планирования Список кандидатов Требования: специализация, квалификация, занятость Система управления персоналом Система управления документами Задания исполнителям Изменение статуса сотрудника Руководитель ресурсного подразделения Заявка на персонал проекта (зарегистрированная) Уведомление о выделении персонала 24
Организационная схема ИТ- проекта (взгляд Исполнителя) 25
Организационная схема ИТ - проекта (взгляд Заказчика) 26
Организационная схема ИТ - проекта (общий взгляд) 27
Многоуровневая структура управления проектами Положения, регламенты взаимодействия, процедуры, инструкции, шаблоны 28
Руководитель проекта и технический лидер 29
Функции органов управления проектом Роль Функция Управляющий комитет ● Планирование и координация хода работ по мультипроекту в целом ● Обеспечение запланированных работ необходимыми ресурсами ● Осуществление контроля хода работ и использования выделенных ресурсов ● Определение основных параметров проектов, утверждение и корректировка их бюджетов Группы управления проектами ● ● ● ● Оперативное управление ходом проекта Обеспечение выполнения запланированных работ Принятие всех решений, не требующих изменения бюджета проекта Подготовка предложений по изменениям в планах Координация технических и людских ресурсов Координация деятельности рабочих групп проекта Организация процесса согласования и утверждения выходных материалов проекта Рабочие группы по направлениям ● Выполнения проектных работ по конкретным направлениям в соответствии с оперативными планами работ ● Представление всей необходимой отчетной документации Экспертный совет ● Рассмотрение принципиально важных технических решений ● Экспертиза материалов и подготовка рекомендации и предложения руководящих структур Совет конструкторов ● Рассмотрение и принятие технических решений ● Подготовка материалов для рассмотрения на Экспертном совете 30
Команда управления проектом Директор проекта ● Контроль хода выполнения и бюджета проекта, утверждение изменений проекта, влияющих на сроки и бюджет проекта. ● Организационное и ресурсное обеспечение проекта ● Разрешение возникающих проблем Руководитель проекта – ● ● Планирование и оперативное руководство работами по проекту Контроль сроков и качества исполнения работ Исполнителем Контроль соблюдения контрактных условий Решение возникающих проблем (в пределах своей компетенции) Администратор проекта ● Решение организационных вопросов по взаимодействию представителей Заказчика и Исполнителя ● Организация рассмотрения, согласования и утверждения отчетных документов ● Ведение управленческой и содержательной документации проекта Технический лидер (Системный архитектор, ГИП, …) ● контроль разработки и согласования технических решений и спецификаций продукции ● контроль и обеспечение качества результатов работ по проекту 35
Квалификационные требования к управленческому персоналу проекта Область управления Роль в проекте Директор проекта Руководитель проекта Администратор проекта Содержание и границы Определение проекта (постановка целей проекта, измерение выгод, оптимизация ограничений) План управления проектом (анализ продукта, Отчетность о контроле и определение альтернатив, анализ изменениях содержания и границ выгод/затрат, WBS, постановка задач) Время Планирование и контроль по вехам Разработка расписания и ресурсного плана, оценка продолжительности работ, контроль сроков Стоимость Формирование управленческого Формирование и исполнению бюджета резерва, анализ cost-benefits проекта (смета, бюджет непредвиденных затрат, финансовые потоки) Выдача заданий, учет трудозатрат, оценки затрат по завершению Отклонения Утверждение изменений и мероприятий по снижению рисков и решению проблем Идентификация, анализ, оценка рисков; анализ и решение проблем; управление изменениями Отчетность по рискам, проблемам, изменениям Качество Утверждение требований к качеству Определение стандартов и правил Процедуры управления проектом; шаблоны и правила заполнения документов Персонал Утверждение распределения ролей и ответственности, разрешение конфликтов Распределение ролей и ответственности, формирование оргструктуры и команды проекта, психология командной работы (руководство и лидерство, мотивация, конфликты) Отчетность по управлению персоналом Коммуникации Рассмотрение тупиковых ситуаций, обзоры хода проекта, представительство на уровне высшего руководства Проведение переговоров, отчетность (статус проекта, анализ стоимости, тенденций, отклонений), доступ к проектным папкам Ведение библиотек и архивов, коммуникационные технологии, организация совещаний Контракты Схемы и источники финансирования, утверждение партнеров и субподрядчиков Планирование поставок, оценка предложений, Контроль поставок и оплат выбор партнеров и субподрядчиков Отчетность о контроле и изменениях в расписании 36
Международная Система Сертификации специалистов по Управлению Проектами Основные характеристики системы сертификации ● является четырехуровневой ● учитывает особенности национальной культуры и компетентность специалистов ● является универсальной ● утверждена Международной ассоциацией управления проектами Виды сертификации ● Сертификат уровня A - Сертифицированный директор программ и проектов (Certified Project Director - CPD) ● Сертификат уровня В - Сертифицированный управляющий проектом (Certified Senior Project Manager - CSPM) ● Сертификат уровня С - Сертифицированный профессионал по управлению проектами (Certified Project Manager - CPMP) ● Сертификат уровня D - Сертифицированный специалист по управлению проектами (Certified Project Management Associate - CPMA) 39
Корпоративный стандарт управления проектами Мастерская 2. Проектный учет и отчетность 43
Мастерская 2. Проектный учет и отчетность Общие сведения Цель мастерской ● Практическая разработка фрагмента корпоративного стандарта управления проектами (Должностные и ролевые инструкции). ● Построение программы обучения персонала в рамках внедрения проектных методов управления Формат мастерской ● Время выполнения – 3 часа ● Мастерская включает краткое вводное сообщение преподавателя, выполнение задания, презентации полученных результатов, заключительное обсуждение. ● Все этапы выполняются в режиме групповой работы Правила «мозгового штурма» ● ● Процесс генерации идей и процесс их обсуждения - разделены во времени Критика возникающих идей запрещена Обсуждение в малых группах Управляемое структурирование полученных идей 44
Мастерская 2. Проектный учет и отчетность Описание бизнес-кейса Описание Компании Рабочее время каждого сотрудника проектно-ориентированного предприятия делится на проектное время и непроектное. Непроектным временем сотрудника распоряжается начальник подразделения, проектным – руководители проектов, в которых задействован сотрудник. Следовательно, сотрудник единовременно имеет не одного, а двух, а то и больше, непосредственных руководителей, распоряжения которых он должен выполнять и перед которыми он должен отчитываться о выполнении работ. Оптимальный период отчетности в проектно-ориентированных организациях составляет одну неделю. Задания по проектам, включая изменения, уточнения, дополнения, могут поступать исполнителю по несколько раз в день. Даже элементарный учет и отчетность в этих условиях может вырасти для сотрудника в самостоятельную и часто трудноразрешимую проблему. Для того, чтобы эта ситуация не стала источником конфликтов и стрессов, должны быть созданы четкие и простые в исполнении правила, закрепленные в стандарте на уровне проектных процедур. Эти правила должны регламентировать порядок выдачи и согласования заданий, учета затрат рабочего времени, разрешения конфликтных ситуаций и т. д. 45
Мастерская 2: Проектный учет и отчетность Бизнес-кейс HR-департамент крупной проектно ориентированной компании получил задание составить программу обучения персонала компании, вовлеченного в проектную деятельность. Топ-менеджер (спонсор проекта) Выделены четыре основные проектные роли: ● Специалист (исполнитель), ● Руководитель проекта (менеджер проекта), ● Руководитель функционального подразделения (владелец ресурсов), ● Спонсор проекта (топ-менеджер компании). На рисунке показаны основные потоки учетной и отчетной информации, возникающие при исполнении проектов компании. В схему включен проектный офис, на который возложены все функции по фиксации событий, происходящих в проекте. Руководитель подразделения Проектный офис Менеджер проекта Специалист Стандартный учет и отчетность Отчетность по изменениям Задание Для каждой из перечисленных ролей и для проектного офиса указать, что именно должен знать и уметь сотрудник, выполняющий эту роль в проекте в части планирования работ, выдачи/получения заданий и отчетности. 46
Мастерская 2: Проектный учет и отчетность Вариант решения Специалист: ● ● ● От кого и в какой форме получать задания Что делать, если задания накладываются по срокам Как выстроить приоритеты выполнения заданий В какой форме отчитываться о выполнении задания и кому направлять отчеты Что считать проблемой и кому сообщать о возникающих проблемах Перед кем и в какой форме ставить вопрос о необходимости пересмотра объема и/или сроков выполнения работ ● Как рассчитать свой бонус от участия в проекте Менеджер проекта: ● ● Как разработать смету трудозатрат проекта Из чего складывается и в какой форме описывается бюджет проекта Как переводить трудозатраты в финансы и наоборот Как управлять стоимостью проекта, какие отслеживать показатели (индексы) стоимости ● Что делать в случае возникновения конфликта ресурсов ● Как проводить изменение бюджета проекта ● Как рассчитать прибыль проекта и премии сотрудников 47
Мастерская 2: Проектный учет и отчетность (вариант решения) Руководитель подразделения: ● Как классифицировать работы, выполняемые сотрудниками подразделения (chargeable/non-chargeable, bonusable/non-bonusable) ● Какой портфель проектов является оптимальным для подразделения ● Как планировать и контролировать трудовые и финансовые ресурсы портфеля проектов подразделения ● Как выровнять мотивацию к выгодным и невыгодным проектам и обеспечить лояльность сотрудников ● В какой форме фиксируется «продажа» сотрудника в проект и доход от «продажи» ● Как отозвать сотрудника из проекта ● Как распределить накладные расходы между проектами Проектный офис: ● ● ● Как открыть/закрыть проект Как сформировать плановый фонд рабочего времени Как фиксировать в учетной системе проектные затраты Какова процедура начисления премий по проектам Как и какие отчеты формировать по проектам Спонсор проекта: ● На какую кнопку нажать, чтобы получить отчет по проекту (где находится последний отчет по статусу проекта) 48
Корпоративный стандарт управления проектами Раздел 9. Базовые элементы стандарта управления проектами 9. 1. Управление предметной областью (содержанием и границами) проекта 9. 2. Управление по временным параметрам 49
Управление предметной областью проекта Процессы и функции Определение (концепция) предметной области Планирование предметной области ● Определение бизнесцелей, ради которых реализуется проект, и критериев их достижения ● Распределение ответственности за управление предметной областью ● Мониторинг состояния внешнего и внутреннего окружения проекта ● Структурная декомпозиция проекта, определение состава работ ● Анализ динамики требований и отклонений в конфигурации продукта ● Определение критериев оценки проекта и базовых значений показателей ● Формирование заявок на изменения, внесение принятых изменений и доведение информации до участников ● Определение продукта проекта и его основных характеристик ● Определение предположений и ограничений ● Анализ альтернатив и выбор варианта реализации проекта ● Разработка и утверждение ● Формирование плана управления предметной областью Контроль, анализ и регулирование предметной области Завершение ● Формирование архива проекта ● Заключительный анализ и оценка результатов проекта ● Извлечение уроков ● Концепции управления предметной областью 50
Управление предметной областью проекта Разделение ответственности Управление бизнесом Бизнес-цели Управление проектом Критерии достижения Предположения и ограничения Управление требованиями Управление составом работ Управление конфигурацией Управление продуктом Ответственность Спонсора проекта Ответственность Руководителя проекта Ответственность технического руководителя Управление составом работ ● Процессы, необходимые для обеспечения того, что в проект включены все требуемые работы и только те работы, которые необходимы для успешного завершения проекта Управление требованиями ● Процедуры управления специальными требованиями заказчика к результатам проекта, а также для оборудования, материалов, услуг и процедур управления, включающих количественные и качественные характеристики Управление конфигурацией ● Процедуры используемые для технического и административного руководства работами, связанными с созданием, поддержанием и контролем за изменениями в конфигурации продукта на протяжении его жизненного цикла 51
Структурная декомпозиция работ Структурная Декомпозиция Работ (WBS, СДР) ● Иерархическая структуризация работ проекта, ориентированная на основные результаты и работы проекта, определяющие его содержание ● Каждый нижестоящий уровень структуры представляет собой детализацию элемента высшего уровня проекта ● Элементом проекта может быть как продукт, услуга так и пакет работ или работа В стандарте управления проектами могут быть определены типовые СДР, использующие различные подходы к декомпозиции проектов: ● по компонентам ИС (программные, технические, информационные), ● по технологическим этапам (концепция, техническое задание, проектирование и т. д. ), ● по исполнителям, ● по заказчикам и т. д. Возможно построение универсального шаблона СДР, в котором будут поддерживаться взгляды различных заинтересованных лиц (взгляд куратора, взгляд руководителя проекта, взгляд инвестора и т. д. ) 52
Структурная декомпозиции работ Декомпозиция работ по различным основаниям 53
Структурная декомпозиции работ Декомпозиция работ по исполнителям 54
Декомпозиция программы по целевому назначению проектов 55
Декомпозиция комплексного проекта по стадиям и этапам работ 56
Структурная декомпозиции работ Практические соображения Главный принцип построения - управляемость элемента (единая точка ответственности, делегирование ответственности вниз): ● Строится сверху вниз от общего к частному (дедуктивно). Каждый «родительский» элемент строго равен элемент равен сумме «дочерних» , не допускаются повторы, перекрытия, неопределенность завершения ● В качестве названий элементов использовать существительные (для результатов) или глаголы (для работ) ● Каждому контрактному (поставляемому Заказчику) результату (услуге) и каждому результату от поставщиков в СДР ставить в соответствие отдельный элемент ● Не детализировать больше, чем надо. Степень детализации у каждого элемента своя. Не разбивать один элемент более чем на 20 (лучше до 15) элементов. Проекты среднего уровня сложности не должны иметь более 7 ми (лучше 5 -ти) уровней детализации ● За одно совещание определять не более двух-трех уровней детализации ● Согласовать СДР с руководителями и исполнителями 57
Структура декомпозиции работ Практические соображения Проект Результат 1 Результаты 1 2 3 Результат 2 Компонент 2. 1. Компонент 2. 2. Компоненты 2. 1. 2. 2. 4 2. 3. Пакет работ 2. 2. 1. Результат 3 Компонент 2. 3. Пакет работ 2. 2. 2. Пакеты работ Работы 2. 2. 1. (до элементарных) 2. 2. 2. 1. 2. 2. 3. Работа 2. 2. 2. 3. 58
Структура декомпозиции работ Практические соображения Пример: Фрагмент из PMI Practice Standard for WBS «SW Implementation Project WBS example” 59
Управление проектом по временным параметрам Процессы и функции Концепция управления по временным параметрам ● Определение концептуальной последовательности работ и принципиальных взаимосвязей ● Определение контрольных дат и ключевых событий ● Формирование организационного, методического и программного инструментария ● Инициация работ по календарному планированию Формирование календарного плана проекта ● Распределение ответственности за управление по временным параметрам ● Оценка продолжительности работ ● Построение и оптимизация комплексного календарного плана с учетом взаимосвязей работ и ресурсных ограничений Контроль, анализ и регулирование по временным параметрам ● Учет выполненных работ ● Выявление и анализ отклонений в расписании ● Прогнозирование хода выполнения работ ● Формирование заявок на изменения, внесение принятых изменений и доведение информации до участников Завершение ● Фиксация сетевого графика проекта по завершении проекта ● Заключительный анализ и оценка календарного планирования проекта ● Извлечение уроков 60
Управление проектом по временным параметрам Уровни детализации календарного плана Пример: Структура календарных планов строительства АЭС Уровень-1 Календарный план ключевых событий проекта (200 работ) Уровень-2 Укрупненный календарный план (20000 работ из них 10000 по строительству) Уровень-3 Детальный календарный план (32000 Работ 70000 ограничений) Уровень-4 (400 -500 тыс. пакетов работ) Уровень-5 Оперативный двухнедельный график работ с указанием на каждый день 61
План по вехам (Milestone plan) План по вехам – это самый действенный инструмент планирования, контроля и управления (спонсорский): ● Составляется «с конца» , начиная с события успешного завершения проекта (достижения цели, получения результата). ● Последовательно слой за слоем формулируются все предшествующие события, «необходимые и достаточные» для наступления каждого из последующих событий. ● Каждому событию ставится в соответствие время его наступления, ответственный и критерий подтверждения наступления. ● План по вехам должен быть легко обозримым (не более 1 -2 страницы). Достижение вех должно быть согласовано со всеми участниками: ● ● Каждая из вех станет контрольной точкой и должно быть включено в план контроля и отчетности для руководства Достижение каждой из контрольных точек должно быть спланировано и скоординировано в подготовленных более детальных планах исполнителей Преимущества плана по вехам ● ● Простота Очевидность целей, задач и результатов проекта Четкое представление структуры проекта Конкретность, необходимая для мобилизации ресурсов на достижение конечной цели 62
План по вехам Пример № 1 63
Рабочая документация выдана Экспертиза ПД завершена Оплачена экспертиза ПД Проектная документация выдана Вехи стадии проектирования … Работы на объекте начаты Вехи стадии строительства … Объект зарегистрирован Пакет правоустанавливающих документов подготовлен Ввод объекта в эксплуатацию Объект сдан в эксплуатацию Строительство объекта Работы на объекте завершены Заявочная кампания Разрешение на строительство получено Оформление Проектирование заданий на объекта проектирование Подрядные договора заключены Формирование ПКС Сбор исходных данных завершен Предпроектные проработки завершены Оформлено задание на проектирование План по вехам Пример № 2. EPC-проект Жизненный цикл объекта Эксплуатация объекта 64
План по вехам Пример № 3. Проект внедрения ERP-системы KPI определены 1. 2. 4 1. 1. 1 Требования готовы 1. 1. 2 1. Формирование требований пользователей 1. 1. 3 Стандарт готов 1. 1. 4 1. 2 Проектные решения готовы 1. 3 2. Разработка стандарта по бизнеспроцессам 2. 1 3. Разработка и внедрение ИТ системы 1 фев 2. 2 2. 3 Система внедрена Платформа выбрана 3. 1. 1 3. 1. 2 ТЗ готово 3. 1. 3 3. 1. 4 3. 2 3. 3 Пилот выбран 1 апр 1 июн 1 июл 15 сен 31 дек 65
Сетевые графики Ключевые понятия сетевого планирования: ● Сеть, Метод сетевого планирования, Путь, Узел, Дуга, Событие, Работа Формы представления ● Диаграмма Гантта B C Диаграмма предшествования ● A Конец Начало D E F Методы расчета ● ● Прямой проход - вычисление дат раннего начала и раннего окончания для незаконченных частей всех работ сети. Обратный Проход - расчет сроков поздних начал и поздних окончаний для незавершенных частей всех работ сети. Определяется путем последовательного обратного просмотра на сети каждой работы, начиная от даты завершения проекта до 66 даты его начала.
Корпоративный стандарт управления проектами Раздел 10. Бюджет проекта и управление стоимостью 10. 1. Ключевые понятия управления стоимостью 10. 2. Планирование стоимости 10. 3. Контроль, анализ и регулирования затрат 10. 4. Показатели освоенного объема 67
Смета проекта Задачи формирования сметы: ● Определить стоимость проекта ● Определить стоимость отдельных работ ● Детализировать стоимость работ с целью учета Детализация смет Смета уровня проекта Приближенные значения стоимости проекта, необходимые для принятия решений по инвестированию, в дальнейшем в целях управленческого контроля не используются Смета уровня работ Значения стоимости отдельных работ проекта, вычисленные с высокой степенью детализации, используемые для управления проектом 68
Элементы стоимости проекта (1 -4) • Трудозатраты – количество единиц труда, требующихся для выполнения работ; обычно вычисляется в человеко-часах, могут быть преобразованы в денежное выражение с использованием известной стоимости ресурсов • Стоимость материалов – денежная величина затрат на материалы, закупленные и потраченные на создание продукта проекта • Затраты на оборудование – денежная величина затрат на материалы, которые используются при производстве продукта, но не расходуются и либо могут использоваться в другом проекте, либо возвращаются владельцу; стоимость оборудования учитывается в затратах по проекту лишь частично • Субподряд – стоимость услуг, внешних подрядчиков 69
Элементы стоимости проекта (5 -10) • Расходы на управление – стоимость труда команды управления проектом (руководитель проекта, администратор проекта) и технических средств управления проектом (офис управления проектом) • Накладные и административные расходы – накладные расходы организации, транспорт, склад • Обязательные выплаты и налогообложение – страховые платежи, налоговые платежи, платежи по лицензионным соглашениям • Инфляция – учитывается в случае разных уровней инфляции для издержек и доходов по проекту, а также в тендерах с фиксированной ценой • Непредвиденные расходы – Распределяются по другим статьям расходов (для заказчика) или показываются отдельной строкой (для команды проекта) • Затраты на финансирование – расходы на обслуживание кредитов 70
«Куб» стоимости проекта План счетов бухгалтерского учета Результат 1 Сметная стоимость работ уд И т. д. ат ра ты ри ал ы те И т. д. Ресурс 2 д. Структурная декомпозиция организации оз де Ма ко С мп т оз рук иц ту ия рн с ая то им ос Тр ти Результат 2 Ресурс 1 Структурная декомпозиция работ Матрица распределения ответственности Источник: Тернер Дж. Руководство по проектно-ориентированному управлению 71
Бюджет проекта Задачи формирования бюджета проекта: ● Привязать доходы и расходы к календарным срокам ● Определить величину финансовых резервов в проекте ● Определить источники финансирования Структура бюджета проекта Общий бюджет проекта Бюджет непредвиденных затрат (на «неизвестные неизвестности» ) Операционный бюджет (сметы затрат) Управленческий резерв (на «известные неизвестности» ) 72
Бюджет программы Задачи формирования бюджета программы: ● Определение потребности в финансировании отдельных направлений программы, исходя из логики ее реализации ● Формирование плана финансирования проектов в привязке к календарным периодам (год, квартал) Стадии формирования бюджета программы Предварительный бюджет Рамочный бюджет Годовой бюджет Формируется на предконтрактной стадии для проведения конкурсов и тендеров Формируется на стадии заключения контрактов и определяет весь объем финансирования по проектам (лотам) Формируется на каждый год с учетом необходимого финансирования каждого проекта в данном году 73
Бюджет портфеля проектов Задачи формирования бюджета портфеля: ● Анализ достаточности ресурсов, необходимых для реализации проектов, включенных в программы ● Поддержание баланса финансирования отдельных направлений с точки зрения инвестиционных рисков Пример: модель Уэйла – риски в обмен на прибыль 1. Вложения в инфраструктуру (умеренные риски) 2. Инвестиции в системы обработки транзакций (минимальные риски, коэффициент окупаемости 25% - 40%) 3. 4. Вложения в информационные системы (умеренные риски) Стратегические инвестиции (самые высокие риски – 10% инвестиций дают впечатляющие результаты, 50% даже не окупаются) 3 4 14% 13% 2 28% 1 45% MIT CISR, 2007 74
Принципы формирования бюджета портфеля инвестиционных проектов Бюджет развития Основные направления инвестиций AA% BB% Портфель А CC% Портфель C Портфель B DD% Портфель D EE% Портфель E Направления инвестиций в ИТ Умеренные риски - 45% Минимальные риски - 28% Внедрение учетных систем Развитие инфраструктуры Умеренные риски - 14% Внедрение аналитических систем Высокие риски - 13% Стратегические инвестиции в ИТ Ранжированный список проектов внедрения учетных систем Rang 1 (max) Проект 1 Rang 2 Проект 2 Rang 3 Проект 3 Rang 4 Проект 4 …… Rang N (min) Проект N Уровень отсечения на текущий год 75
Трехуровневая система бюджетов проектноориентированной компании Бюджет компании Финансирование корпоративных проектов Корпоративный налог Бюджет подразделения Оплата специалистов Финансирование проекта подразделения Оплата специалистов Выручка от продажи Бюджет коммерческого проекта Прямые затраты Проекты с внешним финансированием Бюджет проекта подразделения Прямые затраты Бюджет корпоративного проекта Прямые затраты Проекты с внутренним финансированием 76
Процессы управления стоимостью Концепция проектного финансирования ● Финансовый анализ (изучение финансовых потоков и возможных источников финансирования) ● Экономический анализ (маркетинг, оценка затрат и прибыли, реальность выполнения, риски и резервы) ● Формирование предварительного финансового плана и анализ чувствительности ● Определение возможных дополнительных источников финансирования ● Тестирование финансового плана, проведение предварительных переговоров с потенциальными кредиторами Планирование стоимости ● Распределение ответственности за управление стоимостью и финансами ● Планирование ресурсов ● Оценка стоимости ● Формирование сметы и бюджета ● Уточнение финансового плана Контроль, анализ и регулирование стоимости Организация проектного финансирования ● Учет стоимости выполненных работ ● Учёт поступлений и расходов, анализ их отклонений от бюджета проекта ● Анализ и прогнозирование финансовых потоков ● Формирование заявок на изменения, внесение принятых изменений и доведение информации до участников ● Проведение внутренних и внешних финансовых аудитов ● Финансовые отчеты для заинтересованных сторон ● Фиксация поступлений и расходов в соответствие с планом счетов проекта в бухгалтерской системе ● Бухгалтерская отчётность Завершение ● Заключительный анализ и оценка стоимости и финансирования ● Экономическая оценка результатов ● Окончательные расчеты и закрытие финансирования ● Фиксация сметы по завершении проекта ● Формирование заключительного финансового отчета ● Извлечение уроков 77
Основные этапы планирования стоимости проекта Определение содержания и границ Формирование СДР (WBS) Формирование стоимостных оценок Лучшие практики Формирование Плана по вехам (Milestone Plan) Формирование сметы Отраслевые нормы Определение и анализ рисков Формирование бюджета проекта Определение оргструктуры проекта Определение центров ответственности Конъюнктура рынка 78
Формирование стоимостных оценок Задача – ● Сформировать укрупненные приближенные оценки, необходимые для принятия решений по целесообразности продолжения переговоров и по открытию проекта или по инвестированию (для управленческого контроля в дальнейшем не используются). Методы – ● Экспертные оценки - укрупненные, по проекту в целом, на основе обобщенных и взвешенных мнений экспертов, чаще всего на ранних стадиях при недостатке информации (оценки «порядка величины» ) ● Оценки по аналогам - найти аналогичный проект; сопоставить размеры, сложность, условия выполнения, влияющие на стоимость проектов; произвести оценку по аналогу с учетом различий проектов ● Параметрические оценки - общая стоимость проекта рассчитывается по математической модели на основе ряда характеристик (параметров): § Дома стоят $1000 за кв. метр, Самолёты $400 за килограмм, Программы $4 за команду и т. п. § Параметрические уравнения могут иметь несколько переменных § Стоимость работы обычно состоит из фиксированной части и параметрически определяемой переменной части. § Строительство офисного здания обойдётся $800 за квадратный метр, плюс $125 за кубический метр, плюс $100 квадратный метр земли, плюс $40000 за согласования, плюс т. д. 79
От оценки к смете 50% Принятие решения об инициации проекта Точность оценки 40% Заявочная оценка Обоснование выделения ресурсов на проектирование и экспертизу Получение финансирования со стороны инвестора Бюджетная оценка 30% Планирование реализации проекта Утвержденная оценка 20% Контрольная оценка 10% Тендерная оценка Подготовка предложения для участия в конкурсе 0, 02% 0, 05% 0, 1% 0, 2% 0, 5% 1, 0% 2, 0% 5, 0% Стоимость оценки как доля стоимости проекта 10, 0% Источник: Тернер Дж. Руководство по проектно-ориентированному управлению 80
Структура сметы проекта Объект 1 Объект 2 Объект 3 Трудозатраты $$$ $$$ Материалы $$$ $$$ Оборудование $$$ $$$ Субподряд $$$ $$$ Затраты на управление $$$ $$$ Административные расходы $$$ $$$ Налоги $$$ $$$ Инфляция $$$ $$$ Непредвиденные расходы $$$ $$$ Расходы на финансирование $$$ $$$ Статья затрат Возможна детализация по продуктам, если на одном объекте внедряется несколько продуктов или работает несколько субподрядчиков 81
Структура расходной части бюджета Объект 1 Объект 2 Объект 3 Трудозатраты Дата - $ Дата - $ Дата - $ Материалы Дата - $ Дата - $ Дата - $ Оборудование Дата - $ Дата - $ Дата - $ Субподряд Дата - $ Дата - $ Дата - $ Затраты на управление Дата - $ Дата - $ Дата - $ Административные расходы Дата - $ Дата - $ Дата - $ Налоги Дата - $ Дата - $ Дата - $ Инфляция Дата - $ Дата - $ Дата - $ Непредвиденные расходы Дата - $ Дата - $ Дата - $ Расходы на финансирование Дата - $ Дата - $ Дата - $ Статья затрат 82
Финансовые потоки в проекте Май Июнь Июль Август + Оплата оборудования и ПСД Оплата СМР и ПНР - - - - - ТМЦ Доставка ТМЦ - - + - - Субподряд Прочие расходы Расходование резервов Заимствования Декабрь Аванс Налоги Командировки Ноябрь + + Платежи от заказчика Зарплата Октябрь Поставка оборудования Разработка ПСД Заключение договора Вехи проекта Сентябрь Пусконаладочные работы (ПНР) Апрель Строительномонтажные работы (СМР) Месяц - - - + 83
Метод PERT Назначение Оценка трудоемкости на основе ограниченного количества оценок трудозатрат – оптимистической, пессимистической и наиболее вероятной Достоинства • Низкие затраты на оценку • Достаточная реалистичность оценок Историческая справка Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис» Дополнительные требования Расчет опирается на центральную предельную теорему теории вероятности и требует статистически независимых оценок отдельных пакетов работ проекта. Следует избегать как необоснованного оптимизма, так и чрезмерного пессимизма. 84
Детализация оценок Задача – ● Сформировать сметы уровня работ – оценки с более высокой степенью детализации, определенности и точности для использования при управлении проектом и его оценке Вероятностный характер стоимостных оценок ● Оптимистическая оценка – наименьшая сумма затрат по завершения работы, предполагая, что все идет как надо. ● Наиболее вероятная оценка – наилучшая возможная сумма затрат по завершения работы с учетом реалистичного плана и обычных внешних и внутренних влияний. ● Пессимистическая оценка – наибольшая возможная сумма затрат по завершению работы, предполагающая наличие всех возможных задержек и проблем, которые могут возникнуть в нормальном процессе. 85
Вероятность осуществления Расчет вероятностных оценок Смета PERT = (O + 4 ML + P)/6 Оценка с наибольшей вероятностью 25 Оптимистическая оценка Смета 1 = (O + ML + P)/3 30 32 35 50 Величина расходов Пессимистическая оценка 86
Расчет стандартных отклонений Интервал Вычисления Наиболее Стандартное Пессимисти- Ожидаемая вероятная Дисперсия отклонение ческая оценка величина оценка Работа 1 10 20 30 20 44 Работа 2 30 40 80 50 278 Работа 3 15 20 30 22 25 Работа 4 25 30 55 37 100 Работа 5 25 30 45 33 44 Работа 6 20 40 80 47 400 Работа 7 Оптимистическая оценка 65 70 110 82 225 290 1116 250 33 Ожидаемая величина – среднее значение оптимальной, наиболее вероятной и пессимистической оценок Дисперсия – квадрат разности пессимистической и оптимистической оценки деленной на 3 Стандартное отклонение – квадратный корень из дисперсии 87
Расчет финансовых резервов Ожидаемые затраты Вероятность осуществления 290 Резерв 0∑ 323 Наиболее вероятные затраты 250 324 Резерв -2∑ 1% 50% Резерв 1∑ 84% 356 99% Резерв 2∑ Потенциальные выходы 88
Метод функциональных точек (IAFPUG) Назначение Оценка трудоемкости на основе логической модели объема программного продукта, измеренного количеством функционала, востребованного заказчиком и поставляемого разработчиком Достоинства • Измерения не зависят от технологической платформы • Метод обеспечивает единообразный подход к оценке всех проектов в компании Историческая справка Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 1970 -х годов. Впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (IAFPUG), которая опубликовала несколько ревизий метода. Дополнительные требования Помимо функциональных требований на продукт накладываются общесистемные требования, которые ограничивают разработчиков в выборе решения и увеличивают сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта 89
Определение функциональных точек N Тип функциональной точки Функциональные точки 1 Функциональные точки, связанные с данными Внутренние логические файлы (ILFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, которые поддерживаются внутри продукта Внешние интерфейсные файлы (EIFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, на которые ссылается продукт, но которые поддерживаются вне продукта 2 Функциональные точки, связанные с транзакциями EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему извне EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF. EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF 90
Подсчет функциональных точек, связанных с данными Матрица сложности данных 1 -19 DET 20 -50 DET 50+ DET 1 RET Low Average 2 -5 RET Low Average High 6+ RET Average High DET (Date Element Type) – неповторяемое уникальное поле данных High RET (Record Element Type) – логическая группа данных Оценка данных в не выровненных функциональных точках Сложность данных Количество UFP (ILF) Количество UFP (EIF) Low 7 5 Average 10 7 High 15 UFP – количество функциональных точек 10 ILF - внутренние логические файлы EIF - внешних интерфейсные файлы 91
Подсчет функциональных точек, связанных с данными: пример ИЛИ Источник: Архипенков С. Лекции по управлению программными проектами 92
Подсчет функциональных точек, связанных с транзакциями Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ) Матрица сложности внешних входных транзакций (EI) EI 1 -4 DET 5 -15 DET 16+ DET EO & EQ 1 -5 DET 0 -1 FTR Low Average 2 FTR Low Average High 2 -3 FTR Low Average High 3+ FTR Average High 4+ FTR Average High 6 -19 DET 20+ DET FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции. DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска. Сложность транзакций в не выровненных функциональных точках (UFP) Сложность транзакций Количество UFP (EI & EQ) Количество UFP (EO) Low 3 4 Average 4 5 High 6 7 UFP – количество функциональных точек EI – внешние входные транзакции EO - внешние выходные транзакции EQ – внешние запросы 93
Подсчет функциональных точек, связанных с транзакциями: пример Источник: Архипенков С. Лекции по управлению программными проектами 94
Факторы выравнивания (1 -7) Обмен данными (0 — продукт представляет собой автономное приложение; 5 — продукт обменивается данными по более, чем одному телекоммуникационному протоколу). Распределенная обработка данных (0 — продукт не перемещает данные; 5 — распределенная обработка данных выполняется несколькими компонентами системы). Производительность (0 — пользовательские требования по производительности не установлены; 5 — время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа. Ограничения по аппаратным ресурсам (0 — нет ограничений; 5 — продукт целиком должен функционировать на определенном процессоре и не может быть распределен). Транзакционная нагрузка (0 — транзакций не много, без пиков; 5 — число транзакций велико и неравномерно, требуются специальные решения и инструменты). Интенсивность взаимодействия с пользователем (0 — все транзакции обрабатываются в пакетном режиме; 5 — более 30% транзакций — интерактивные). Эргономика (эффективность работы конечных пользователей) (0 — нет специальных требований; 5 — требования по эффективности очень жесткие). 95
Факторы выравнивания (8 -14) Интенсивность изменения данных (ILF) пользователями (0 — не требуются; 5 — изменения интенсивные, жесткие требования по восстановлению). Сложность обработки (0 — обработка минимальна; 5 — требования безопасности, логическая и математическая сложность, многопоточность). Повторное использование (0 — не требуется; 5 — продукт разрабатывается как стандартный многоразовый компонент). Удобство инсталляции (0 — нет требований; 5 — установка и обновление ПО производится автоматически). Удобство администрирования (0 — не требуется; 5 — система автоматически самовосстанавливается). Портируемость (0 — продукт имеет только 1 инсталляцию на единственном процессоре; 5 — система является распределенной и предполагает установку на различные «железо» и ОС). Гибкость (0 — не требуется; 5 — гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме). 96
Расчета количества функциональных точек Количество не выровненных функциональных точек Значение фактора влияния (VAF) TDI = ∑ DI TDI - total degree of influence: DI - degree of influence оцениваются по шкале от 0 до 5. Суммарное влияние процедуры выравнивания лежит в пределах 35% VAF = (TDI *0. 01) + 0. 65 Расчет количества выровненных функциональных точек (AFP) AFP = UFP * VAF Примечание: метод предлагает уточненные формулы для учета дополнительно реализуемых или модифицируемых функций ОГРАНИЧЕНИЕ: Чтобы перевести количество функциональных точек в стоимость, необходимо иметь статистику по трудоемкости реализации функциональных точек 97
Пример применения метода функциональных точек: адаптация IBM Сложность модуля Простой по сложности модуль – последовательная обработка файлов и создание отчётов с использованием простых алгоритмов, или модуль высокого уровня иерархической структуры, или модуль с «декларативным кодом» . Средний по сложности модуль – стандартная обработка данных, требующая входов от нескольких источников и некоторой сложности в обработке данных; необходимость предусмотреть в модуле несколько случаев возможных сбойных ситуаций и запрограммировать выход из них. Сложный модуль – обработка данных в реальном масштабе времени с асинхронным возникновением событий, на которые модуль должен реагировать, необходимость предусмотреть в модуле много случаев возможных сбойных ситуаций и запрограммировать выход из них, проблемы со временем обработки данных и реакции системы, сложные алгоритмы используются для анализа или принятия решения в модуле. Размер модуля Малый – менее 50 операторов программного кода, Средний – от 50 до 150 операторов программного кода, Большой – более 150 операторов программного кода. 98
Пример применения метода функциональных точек: адаптация IBM Оценка количества модулей по сложности & размеру Матрица трудоемкости в часах, необходимых для квалифицированного специалиста средних способностей для программирования и тестирования модулей Сложность Простой Средний Сложный Размер Малый 15 3 - Малый 4 8 16 Средний 8 6 - Средний 10 20 40 Большой 2 1 1 Большой 25 50 100 Уточнение трудоемкости по характеристикам использования модулей Единичный (Е) – программный модуль уникальный для одной программы – не используется другим программами (например, главный модуль) Сервисный (С) – программный модуль используется нескольким программами (например, утилита файлового доступа). Трудоёмкость разработки такого модуля подсчитываются только один раз для всей программы. Библиотечный (Б) – это уже разработанные модули и они не учитываются при оценке. 99
Пример применения методики функциональных точек: адаптация IBM Расчет трудоемкости программирования и тестирования (в часах) Пр Ср Сл М 15 3 - С 8 6 - Б 2 1 1 Шт. Пр Сл М × Ср 4 8 16 С 10 20 40 Б 25 50 100 Пр Сл М = Ср 60 24 - С 80 120 - Б 50 50 100 Час. Итого М = 84 С 200 Б 200 484 Час. Распределение трудоемкости по стадиям разработки Детальное проектирование Программирование и тестирование модуля Интеграционное тестирование подсистемы Системное тестирование Разработка документации – 15 % – 45 % – 15 % – 10 % 100
Методика COCOMO II (COnstructive COst Model) Назначение Расчет трудоемкости с применением формулы регрессии с использованием параметров, определяемых на основе статистических данных и характеристик конкретного проекта. Различаются две стадии оценки проекта: предварительная оценка на начальной фазе и детальная оценка после проработки архитектуры. Историческая справка COCOMO впервые опубликована Бари Боэмом в 1981, как результат анализа 63 проектов компании «TRW Aerospace» . В 1997 была усовершенствована и получила название COCOMO II. Калибровка параметров производилась по 161 проекту. где • SIZE • Mi • SFj • n=7 • n=17 - размер продукта в KSLOC - множители трудоемкости - факторы масштаба - для предварительной оценки - для детальной оценки Ограничение Для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода (KSLOC, Kilo Source Lines Of Code). Размер программного продукта может быть, например, оценен экспертами с применением метода PERT. 101
Размер программного продукта Оценка количества строк, необходимых на реализацию одной не выровненной функциональной точки для некоторых распространенных языков программирования Язык программирования Оценка количества строк (в тыс. шт. ) Наиболее вероятная Оптимистичная Пессимистичная Assembler 172 86 320 C 148 9 704 C++ 60 29 178 C# 59 51 66 J 2 EE 61 50 100 Java. Script 56 44 65 PL/SQL 46 14 110 Visual Basic 50 14 276 102
Факторы масштаба 1. PREC – прецедентность (опыт аналогичных разработок) • Very Low – опыт в продукте и платформе отсутствует • Extra. High – продукт и платформа полностью знакомы 2. FLEX – гибкость процесса разработки • • Very Low – процесс строгодетерминирован Extra. High – определены только общие цели 3. RESL– архитектура и разрешение рисков • • Very Low – риски неизвестны/не проанализированы Extra. High – риски разрешены на 100% 4. TEAM – сработанность команды • • Very Low – формальные взаимодействия Extra. High – полное доверие, взаимозаменяемость и взаимопомощь 5. PMAT – зрелость процессов • • Very Low – CMM Level 1 Extra. High – CMM Level 5 103
Факторы масштаба: таблица коэффициентов Фактор масштаба Оценка уровня фактора Very Low Nominal High Very High Extra High PREC 6. 20 4. 96 3. 72 2. 48 1. 24 0. 00 FLEX 5. 07 4. 05 3. 04 2. 03 1. 01 0. 00 RESL 7. 07 5. 65 4. 24 2. 83 1. 41 0. 00 TEAM 5. 48 4. 38 3. 29 2. 19 1. 10 0. 00 PMAT 7. 80 6. 24 4. 68 3. 12 1. 56 0. 00 104
Множители трудоемкости для предварительной оценки 1. PERS – квалификация персонала • • Extra. Low – аналитики и программисты имеют низшую квалификацию, текучесть больше 45% Extra. High - аналитики и программисты имеют высшую квалификацию, текучесть меньше 4% 2. RCPX – сложность и надежность продукта • • Extra. Low – продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется Extra. High - продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме 4. PDIF – сложность платформы разработки • • Extra. Low – специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна Extra. High – жесткие ограничения по памяти и быстродействию, платформа нестабильна 5. PREX – опыт персонала • • Extra. Low – новое приложение, инструменты и платформа Extra. High - приложение, инструменты и платформа хорошо известны 6. FCIL – оборудование • Extra. Low – инструменты простейшие, коммуникации затруднены Extra. High – интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации 3. RUSE – разработка для повторного использования • • • 7. SCED – сжатие расписания Low – не требуется Extra. High – требуется повторное использование в других продуктах • • Very. Low – 75% от номинальной длительности Very. High – 160% от номинальной длительности 105
Множители трудоемкости для предварительной оценки: таблица коэффициентов Оценка уровня множителя трудоемкости Extra Low Very Low Nominal High Very High Extra High PERS 2. 12 1. 62 1. 26 1. 00 0. 83 0. 63 0. 5 RCPX 0. 49 0. 60 0. 83 1. 00 1. 33 1. 91 2. 72 RUSE n/a 0. 95 1. 00 1. 07 1. 15 1. 24 PDIF n/a 0. 87 1. 00 1. 29 1. 81 2. 61 PREX 1. 59 1. 33 1. 22 1. 00 0. 87 0. 74 0. 62 FCIL 1. 43 1. 30 1. 10 1. 0 0. 87 0. 73 0. 62 SCED n/a 1. 43 1. 14 1. 00 n/a 106
Расчет трудоемкости разработки многокомпонентного продукта Простая сумма не учитывает взаимосвязи компонентов и трудозатраты на их интеграцию Последовательность вычисления трудоемкости проекта при многокомпонентной разработке: 1. Суммарный размер продукта рассчитывается, как сумма размеров его компонентов: 2. Базовая трудоемкость проекта рассчитывается по формуле: 3. Затем рассчитывается базовая трудоемкость каждого компонента: 4. На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED. 5. И, наконец, итоговая трудоемкость проекта определятся по формуле: 107
Пример финансовой структуры проекта Ответственность по доходам Спонсор ● Поступление средств Коммерческий менеджер ● Маржа ● Поступление средств Ответственность по расходам Спонсор ● Финансовые резервы (неизвестные неизвестности) Руководитель проекта Финансовая служба ● Налоги ● Накладные расходы Руководитель ресурсного подразделения ● Премии ● Управленческий резерв (известные неизвестности) ● Стоимость ресурсов ● Прямые расходы подразделения Субподрядчик ● Все расходы по субподряду ● Все доходы по субподряду 108
Процедуры управления стоимостью ● Формирование бюджета ● Финансовый анализ ● Финансирование ● Отчет о статусе ● Финансовый аудит 109
Процедуры управления стоимостью Формирование бюджета Координатор от Заказчика 3. Подготовка консолидированной заявки 5. Формирование проекта бюджета 4. Оценка и анализ заявки Представитель Инвестора Руководители направлений от Заказчика 2. Подготовка бюджетной заявки Руководитель проекта от Исполнителя 1. Подготовка исходной информации Директор проекта от Заказчика 6. Согласование проекта бюджета 110
Процедуры управления стоимостью Финансовый анализ Координатор от Заказчика 1. Запрос отчета 5. Подготовка предложений Представитель Инвестора Руководители направлений от Заказчика Руководители проекта от Заказчика и Исполнителя Директор проекта от Заказчика 4. Расчет показателей 2. Подготовка отчета 3. Согласование отчета 6. Утверждение плана корректирующих мер 7. Рассмотрение предложений по изменению бюджета 111
Отчетность по стоимости портфеля / проекта Статистика и отчеты о статусе портфеля Состав портфеля Статус портфеля Проектов в портфеле Всего проектов исполняется Инициированные проекты В том числе, без отклонений Завершенные проекты В том числе, с незначительными отклонениями Приостановленные проекты В том числе, со значительными отклонениями Закрытые проекты В том числе, с критичными отклонениями Оценки отдельных проектов Проект Куратор проекта Руководитель проекта Статус проекта Рекомендации 112
Анализ проекта по методу освоенного объема (Earned value analysis) Стоимость Фактическая стоимость выполненных работ AC ACWP BCWS PV BCWP EV Сметная (плановая) стоимость запланированных работ CV = BCWP – ACWP = EV – AC SV = BCWP – BCWS = EV – PV Плановая (сметная) стоимость фактически выполненных работ – освоенный объем Время TV Текущая дата Плановый срок завершения проекта SV – отклонение от календарного графика по запланированной (сметной) стоимости работ (объема, трудоемкости…) SV<0 отставание SV>0 опережение CV – отклонение фактической стоимости выполненных работ от их сметной стоимости CV<0 перерасход CV>0 экономия TV – отклонение от календарного графика по времени, отклонение фактического срока достижения запланированного объёма от планового срока 113
Анализ по методу освоенного объема Отклонения SV + ACWP BCWP < ACWP BCWP > BCWS BCWP > ACWP BCWP > BCWS ACWP BCWS опережение с перерасходом отставание с перерасходом ACWP BCWS опережение с экономией + 0 CV отставание с экономией BCWP < ACWP BCWP < BCWS BCWP > ACWP BCWP < BCWS BCWP ACWP BCWP 114
Анализ по методу освоенного объема Оценки Коэффициенты: CPI = SPI = BCWP ACWP BCWS Коэффициент освоения затрат Используется для прогноза затрат по окончанию проекта Коэффициент выполнения календарного графика Используется для прогноза даты завершения проекта Желтый CPI > 1, SPI < 1 «Бычий Глаз» (по APM Earned Value Management APM Guide for the UK) Зеленый CPI > 1, SPI > 1 Опережение с перерасходо м Опережение с экономией Отставание с перерасходо м CPI < 1, SPI < 1 Отставание с экономией Красный CPI < 1, SPI > 1 Желтый 115
Анализ по методу освоенного объема Прогнозы Стоимость Сметная (плановая) стоимость запланированных работ BCWS=PV Оценка (прогноз) стоимости по Фактическая стоимость завершению (Estimate At Completion - EAC) выполненных работ ASWP = AC Прогноз стоимости до завершения (Estimate To Complete) - ETC Сметная (плановая, бюджетная) стоимость проекта (Budget At Completion) - BAC Время TV Текущая дата Плановая (сметная) Прогнозируемый срок завершения проекта стоимость фактически Плановый срок завершения проекта выполненных работ – освоенный объем. BCWP = EV EAC Оптимистичная = ACWP + BAC - BCWP = AC+(BAC-EV)/CPI=BAC/CPI CPI(+) BAC - BCWP EAC Пессимистичная = ACWP + CPI(+) х SPI(+) Показатель эффективности затрат на будущий период TCPI Плановая стоимость оставшихся работ TCPI = Прогноз стоимости оставшихся работ = BAC - BCWP Х 100% EAC - ACWP 116
Анализ по методу освоенного объема Главные выводы Достоинства метода ● Возможность легко отслеживать общий ход выполнения проекта по стоимости и срокам, фиксируя перерасход или экономию, опережение или отставание ● Возможность раннего обнаружения отклонений в проекте на основании прогнозирования конечных сроков и стоимости ● Удобная форма представления состояния проекта, в том числе с использованием современных программных инструментов Ограничения метода ● Предположение о прямой зависимости между затраченными ресурсами и объемом выполненных работ далеко не всегда подтверждается. ● Неравномерность значения работ и задач в структуре проекта 117
Корпоративный стандарт управления проектами Раздел 11. Проектные отклонения 11. 1. Управление рисками 11. 2. Управление проблемами 11. 3. Управление изменениями 118
Общая схема управления проектными отклонениями 6 Исходное состояние Плана проекта 1 2 3 Управление рисками 5 1 Управление изменениями 2 3 1 4 5 6 1 2 5 Конечное состояние Плана проекта 3 4 Управление проблемами Первый сценарий соответствует полному циклу управления отклонениями Риски, проблемы, изменения тесно связаны между собой и должны рассматриваться в стандарте в рамках единого раздела управления отклонениями. А связи, намеченные на уровне сценариев, должны быть детальным образом прописаны в частных процессах управления рисками, проблемами и изменениями. 122
Управление рисками Процессы и функции Риски возможность нежелательного и незапланированного события, наступление которого может привести к тому, что цели проекта (одна или несколько) не будут достигнуты Концепция управления рисками ● Стратегия управления рисками (цели и задачи, методы анализа и количественной оценки, допустимая степень рисков участников ) ● Выявление факторов рисков и неопределенности ● Регистрация, первичная классификация рисков ● Качественная оценка рисков ● Утверждение концепции Анализ и количественная оценка рисков Планирование мер реагирования ● Уточнение ● Распределение источников рисков ● Уточнение рисковых ● Выбор стратегии событий (факторов работы с риском риска) ● Планирование ● Оценка мероприятий по неопределенности работе с рисками и вероятности события ● Оценка влияние ● Оценка возможных ущербов (степени угрозы) Мониторинг рисков и реагирование ● Реагирование на совершившиеся события ● Анализ состояния рисков и актуализация плана управления рисками ● Контроль использования резервов Завершение ● Анализ и обобщение ● Сводный отчет по управлению рисками ● Отчет по использованию резервов ● Извлеченные уроки Карточка риска № 1 Карточка риска № 2 Карточка риска № Журнал рисков Открыт / анализируется / в работе / закрыт 123
Управление рисками «Таблицы решений» - матрица степени угрозы риска Риск характеризуется тремя составляющими: Количественная характеристика риска: ● Рисковое событие ● Вероятность события ● Ущерб (влияние на проект) ● Степень угрозы – функция влияния и вероятности Вероятность события Влияние на проект Методы анализа рисков: ● ● Метод аналогий Вероятностные методы Экспертные методы Методы имитационного моделирования Низкая Средняя Высокая менее 20% от 20 до 60% более 60% Низкая Средняя Низкая Средняя Высокая Слабое Возможно появление вопросов или проблем в проекте, но вряд ли приведет к нарушению календарного графика, бюджета или ухудшению качества продукта Среднее Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта Сильное Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта Средняя Высокая Критическая 124
Управление рисками Шаблон документа «Карточка риска» 125
Управление рисками Причины неудач ИТ проектов 1. Неспособность Исполнителя адекватно определять ожидания Заказчика от проекта. 2. Контракт с фиксированной стоимостью на оригинальное «решение под ключ» . 3. Заказчик не готов принимать и исполнять свои обязательства по проекту. 4. Не достигнуто и не зафиксировано общее с заказчиком понимание требований к результатам проекта. 5. Обещание на стадии обсуждения контракта выполнить дополнительные обязательства без увеличения стоимости. 6. Неспособность субподрядчиков выполнить свои обязательства. 7. Недооценка ресурсов, времени, стоимости, необходимых для достижения цели проекта. 8. Неспособность управлять рисками проекта. 9. Проблемы с новыми программами, продуктами или оборудованием. 10. Заказчик не готов поддерживать новую систему в эксплуатации. По материалам Владимира Сумцова, Руководителя Проекта, PMP, IBM EE/A 126
Управление рисками Типовые стратегии управления рисками Избежание риска (перенос) Выбор такого проектного решения из возможных альтернатив, которое исключает возникновение рискового события. К этой стратегии относятся действия по изменению контрактной документации для возложения ответственности, связанной с риском, на заказчика или другую сторону, участвующую в проекте. Принятие риска Признание существования риска и отказ от активных мероприятий по противодействию изза их невозможности или нецелесообразности. Принятие этой стратегии предполагает в дальнейшем только отслеживание ситуации для своевременного выявления изменения уровня угрозы (что может потребовать изменения стратегии), или наступления рискового события (что, скорее всего, потребует работы с возникшими в проекте проблемами). Снижение риска (снижение вероятности) Мероприятия направлены на уменьшение вероятности наступления рисковых событий. Снижение риска (уменьшение влияния) Мероприятия уменьшают неприятные последствия от наступления рискового события. К таким мероприятиям относятся создание резервов (финансовых, ресурсных, календарных), составление альтернативных планов проведения работ, рассчитанных на проведение работ в условиях действия предполагаемых последствий рискового события и т. д. 127
Поправки на риск при расчете эффективности инвестиционного проекта Взгляд инвестора 1. Страновые риски 2. Риски ненадежности участников 3. Риски неполучения предусмотренных доходов Конфискация или утеря прав собственности Нецелевое расходование инвестиционных средств Возникновение проблем при реализации технических и технологических решений Ухудшение финансовых показателей из-за изменения законодательства Финансовая неустойчивость компании, реализующей проект Возникновение организационных проблем Изменение трактовок законодательства непрямого действия Недобросовестность, неплатежеспособность, недееспособность подрядчиков или поставщиков Колебание объемов производства и цен на продукцию и ресурсы Величина поправки определяется экспертно и, как правило не превышает 5% Величина поправки составляет от 3% (инвестиции в развитие производства на базе освоенной техники) до 20% (вложения в исследования и инновации) Величина поправки определяется по уровню странового риска инвестирования, определяемому рейтинговыми агентствами 128
Управляемые риски строительного проекта Взгляд руководителя проекта 1. Стихийные риски 2. Технические риски 3. Организационные риски 4. Риски человеческого фактора Негативные природные явления Ошибки проектирования, строительства, монтажа Бюрократические препятствия Профессионализм и ответственность участников Техногенные катастрофы Некачественное сырье, материалы, оборудование Вовлеченность и мотивация Вовлеченность общественности Нарушения техники безопасности, аварии, несчастные случаи Плохое качество коммуникаций Криминальные риски Управление рисками осуществляется в рамках стандартных процессов анализа, планирования, мониторинга и т. д. 129
Кейс. EXPO-2010. Шанхай, Китай Строительство EXPO-2010: § Капитальные затраты - 23 млрд. юаней § Объем строительства – 40 павильонов общей площадью 2 млн м 2, 16 видов муниципальных и вспомогательных проектов Особенности проекта § Строительство осуществлялось в центре Шанхая – в районах Пудонг и Пукси § На строительных площадках работало 27 подрядных организаций и более 1, 5 млн. рабочих § Строительство затронуло жизнь и интересы 6 местных сообществ общей численностью более 3 млн. человек Один из основных рисков проекта: • Человеческий фактор – конфликт интересов подрядных организаций (ПО) и местных сообществ (МС) Принятая стратегия: § Снижение вероятности возникновения конфликтов § Инструмент – обеспечение гармоничного совместного развития сторон © Ma Liang, Le Yun, Li Yongkui, 2009 130
Кейс. EXPO-2010. Шанхай, Китай Математическая модель ситуации Возможности подрядчика Возможности сообщества Предпринимает меры по снижению негативного воздействия строительства на жизнь местного населения и активно решает их проблемы. Помогает в обустройстве быта и медицинского обслуживания рабочихмигрантов, снабжает их книгами, фильмами и т. д. Варианты Своевременные выплаты Отложенные выплаты Активное участие Неактивное участие «Дилемма узника» Некооперативная игра, в которой игроки стремятся получить выгоду, сотрудничая или предавая друга. Предполагается, что игрок ( «узник» ) максимизирует свой выигрыш, не заботясь о выгоде других участников игры. 131
Кейс. EXPO-2010. Шанхай, Китай Математическая модель ситуации Платежная матрица «Равновесие Нэша» Местное сообщество Подрядная организация Своевременные выплаты Отложенные выплаты Активное участие Неактивное участие Желаемая позиция Точка равновесия Каждая из сторон (если не существует других ограничений) будет стремиться минимизировать свои затраты независимо от действий другой стороны. Такое решение позволяет минимизировать затраты в краткосрочной перспективе, но не является оптимальным для всего проекта Изменение «правил игры» возможно только при создании стимулов к сотрудничеству • Необязательные положительные стимулы – награды, присуждаемые третьей стороной • Обязательные отрицательные стимулы – создание гарантийных фондов на случай возникновения финансовых осложнений, применение жестких санкций за несоблюдение правил 132
Кейс. EXPO-2010. Шанхай, Китай Показатели сотрудничества Показатели подрядчика (90 баллов) 1. Достижение целей проекта 2. Безопасность и стабильность Соблюдение сроков проекта и отдельных этапов Мониторинг социальной напряженности Обеспечение качества Защита от природных и техногенных рисков Система управления безопасностью, отсутствие серьезных происшествий Решение проблем местных жителей, своевременная выплата зарплаты 3. Культура строительства Соблюдение норм транспортировки и складирования Защита окружающей среды и покоя местных жителей Своевременное реагирование на жалобы Показатели сообщества (90 баллов) 1. Дружелюбие и радушие 2. Публичность и образование 3. Услуги для EXPO-2011 Содействие созданию зоны безопасности МС Информирование населения о важности проекта Осуществление мер, по помощи строительству Оперативное решение конфликтов Привлечение жителей к участию в проекте Создание необходимых коммуникационных каналов Обслуживание, контроль и обеспечение комфорта строителям-мигрантам Сотрудничество с ПО в вопросах снятия опасений местных жителей Предоставление всех видов услуг на строительной площадке [Конец описания кейса] 133
Корпоративный стандарт управления проектами Мастерская 3. Определение исходных рисков проекта 134
Мастерская 3. Определение исходных рисков проекта Общие сведения Цель мастерской ● Практическое применение знаний по выявлению и анализу проектных рисков ● Практическая разработка фрагмента корпоративного стандарта управления проектами (Начальные риски проекта). Формат мастерской ● Время выполнения – 3 часа ● Мастерская включает краткое вводное сообщение преподавателя, выполнение задания, презентации полученных результатов, заключительное обсуждение. ● Все этапы выполняются в режиме групповой работы Правила «мозгового штурма» ● ● Процесс генерации идей и процесс их обсуждения - разделены во времени Критика возникающих идей запрещена Обсуждение в малых группах Управляемое структурирование полученных идей 135
Мастерская 3. Определение исходных рисков проекта Что нужно знать о рисках Риск характеризуется тремя составляющими: Количественная характеристика риска: ● Рисковое событие ● Вероятность события ● Ущерб (влияние на проект) ● Степень угрозы – функция влияния и вероятности Вероятность события Влияние на проект Методы анализа рисков: ● ● Метод аналогий Вероятностные методы Экспертные методы Методы имитационного моделирования Низкая Средняя Высокая менее 20% от 20 до 60% более 60% Низкая Средняя Низкая Средняя Высокая Слабое Возможно появление вопросов или проблем в проекте, но вряд ли приведет к нарушению календарного графика, бюджета или ухудшению качества продукта Среднее Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта Сильное Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта Средняя Высокая Критическая 136
Мастерская 3. Определение исходных рисков проекта Описание бизнес-кейса Описание Компании Крупный холдинг, занимающийся разведкой месторождений, добычей, переработкой и продажей сырья предполагает осуществить внедрение корпоративной информационной системы. Структура холдинга: ● Управляющая компания, расположенная в Москве. В структуре управляющей компании имеется ИТ-департамент. ● Дочерние предприятия, расположенные в различных регионах России (более десяти). В структуре каждого дочернего предприятия имеется ИТ-служба. Объем внедрения Первая очередь системы будет внедряться в интересах ограниченной группы функциональных заказчиков: ● Департамент финансов управляющей компании ● Департамент разведки месторождений, ● Два дочерних предприятия, выбранных в качестве пилотных объектов. Внешние консультанты Внедрение системы будет осуществляться с привлечением сторонних консультантов. Предполагается привлечение нескольких категорий консультантов: ● Специалисты по специализированным информационным системам в данной предметной области (отрасль добывающей промышленности). ● Специалисты по системам планирования ресурсов предприятия (ERP-системы). ● Специалисты по системной интеграции. 137
Мастерская 3. Определение исходных рисков проекта Задание Вы - Директор ИТ-департамента. Вашей задачей является: ● Разработать перечень рисков проекта ● Определить потенциальные угрозы рисков. ● Оценить степень угрозы рисков. ● Предложить план мероприятий по противодействию рискам. Классификация рисков: ● Организационные риски, ● Риски человеческого фактора, ● Технические риски, ● Финансовые риски. Форма представления результатов: Риск Угроза Вероятность Влияние Степень угрозы Мероприятия 138
Мастерская 3. Определение исходных рисков проекта Вариант решения Организационные риски № Факторы риска Угрозы Мероприятия по снижению риска 1 Недостаточная поддержка проекта Увеличение сроков Выделение ответственного лица со со стороны высшего руководства исполнения работ вплоть до стороны высшего руководства Заказчика, Заказчика их приостановки контролирующего сроки и качество работ по проекту 2 Нарушение баланса интересов участников Скрытый или явный саботаж Формирование организационных структур со стороны отдельных управления проектом, в которых участников обеспечено представительство всех заинтересованных сторон на всех уровнях управления 3 Рассогласование мнения участников по содержательным вопросам Сложность приемки результатов работ и проектной документации Определение регламентов взаимодействия, прав, обязанностей и ответственности участников проекта и органов управления 4 Недооценка сложности проекта Снижение качества результата работ при попытке уложиться в заданные сроки и бюджет Определение необходимого уровня детализации планирования 5 Планирование и использование резервов Недооценка взаимозависимости Позднее выявление ошибок, Раннее выявление взаимосвязей работ за результатов работы рабочих групп простои персонала проекта, счет экспертизы проектных решений и по различным направлениям срыв сроков привлечения экспертов в смежных внутри проекта, а также смежных областях работ Фиксация взаимосвязей в сетевом графике 139
Мастерская 3. Определение исходных рисков проекта Вариант решения Риски человеческого фактора № Факторы риска Угрозы Мероприятия по снижению риска 1 Нежелание части персонала осваивать новые технологии Снижение эффективности внедрения, возникновение напряженности в коллективе Разработка системы мотивации персонала 2 Сложность освоения новых технологий Высокие требования к квалификации персонала Разработка высококачественной пользовательской документации Организация постоянно действующих курсов подготовки персонала 3 Сопротивление руководителей среднего и высшего звена из опасения уменьшения собственной значимости, потери авторитета Невозможность успешного внедрения готовой системы Использование правильных технологий внедрения (в том числе, правильное формирование внедренческих команд) 140
Мастерская 3. Определение исходных рисков проекта Вариант решения Технические риски № Факторы риска Угрозы Мероприятия по снижению риска 1 Неочевидность технических решений, отсутствие аналогов, ориентация на тупиковые технологии Неудовлетворительные Организация процедур внутренней потребительские и внешней экспертизы качества системы (функциональность, эффективность, интерфейсы и т. д. ), невозможность развития системы даже в краткосрочной перспективе 2 Неполнота и неточность Несоответствие исходной информации (в том результатов проекта числе, отсутствие ожиданиям Заказчика формализованного описания бизнес-процессов) Проведение Исполнителем исследования имеющейся документации и своевременно уведомление Заказчика о необходимости проведения дополнительных работ по сбору, анализу и формализации исходных данных 3 Ошибочный выбор программной и/или технической платформы Проведение выбора платформ на тендерной основе, сравнение платформ и обоснование выбора с позиций стоимости владения 141 Высокая стоимость владения
Мастерская 3. Определение исходных рисков проекта Вариант решения Финансовые риски № Факторы риска Угрозы Мероприятия по снижению риска 1 Недостаточное финансирование Невозможность завершения проекта Ранжирование задач по степени важности и поэтапная разработка и внедрение 2 Несвоевременное финансирование Потеря первоначальных инвестиций Корректное формирование бюджета проекта, планирование финансовых резервов 142
Управление проблемами Общая процедура Проблема это вопрос, который возник в процессе осуществления проекта и требует решения, чтобы проект мог идти так, как запланировано. Это исключительные обстоятельства, которые должны быть под контролем (то есть, управляемы) с момента их возникновения Изменение Нерешенная проблема Выявление проблем ● Регистрация проблемы ● Первичная классификация проблемы Анализ и количественная оценка проблем ● Определение источника ● Определение ответственных ● Оценка воздействия на проект ● Определение приоритета проблемы Принятие решений по проблемам ● Выработка решения или ● Эскалация проблемы на вышестоящий уровень управления проектом Исполнение решений по проблеме ● Реализация решения проблемы ● Контроль Закрытие проблемы По завершению проекта: ● Анализ и обобщение ● Сводный отчет по управлению проблемами ● Извлеченные уроки Карточка проблемы № 1 Карточка проблемы № 2 Карточка проблемы № Журнал проблем Открыта / анализируется / в работе / закрыта 143
Управление проблемами «Таблицы решений» - матрица приоритетов проблем Срочность Влияние на проект Слабое Вряд ли приведет к нарушению календарного плана, бюджета или ухудшению качества продукта Среднее Возможно нарушение календарного плана, увеличение стоимости или ухудшение качества продукта Несрочная Первоочередная Неотложная Несущественная Незначительная Важная Особо важная Сильное Возможно значительное нарушение календарного плана, увеличение стоимости или ухудшение качества продукта Особо важные проблемы - требуют немедленного решения с привлечением всех необходимых ресурсов. Важные проблемы - требуют срочного решения с привлечением всех доступных ресурсов. Незначительные проблемы - требуют решения в рамках имеющихся ресурсов без ущерба для остальных работ по проекту. Несущественные проблемы - никакие действия по решению проблемы не предпринимаются до изменения ее приоритета. 144
Управление изменениями Процессы и функции Изменения модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов Концепция управления изменениями ● Определение стратегии изменений (цели и задачи, требования, ограничения) ● Анализ возможных изменений (в контексте проекта, в родительской организации и т. д. ) ● Выбор методов и средств прогнозирова-ния и планирования изменений ● Утверждение концепции Прогнозирование и планирование изменений ● Распределение ответственности ● Мониторинг внешней и внутренней среды проекта ● Прогнозирование изменений ● Планирование предупреждающих воздействий ● Формирование плана управления изменениями Осуществление изменений в проекте ● Регистрация заявок на изменения (причина, суть, классификация, возможные последствия) ● Согласование и утверждение заявок ● Выполнение мероприятий по изменениям ● Информирование заинтересованных сторон Контроль и регулирование изменений ● Контроль осуществления изменений ● Обзор и анализ динамики изменений и отклонений ● Предложения и корректировка плана управления изменениями Завершение ● Анализ и оценка изменений и их результатов ● Сводный отчет по фактическим изменениям в проекте ● Извлеченные уроки Заявка на изменение № 1 Заявка на изменение № 2 Заявка на изменение № Рассматривается / реализуется / отклонена / отложена / реализована Журнал изменений 145
Управление изменениями «Таблицы решений» - диаграммы стратегий изменений Ресурсы Область недопустимых потерь Желаемая стратегия Возможные стратегии Область нежелательных потерь Область приемлемых потерь Область плановых потерь Время Продукты 146
Управление изменениями Стратегия «Ограниченный бюджет» Ресурсы Область недопустимых потерь Область нежелательных потерь Область допустимых потерь Область плановых потерь Время Продукты 147
Управление изменениями Стратегия «Упрямый заказчик» Ресурсы Область недопустимых потерь Область нежелательных потерь Область допустимых потерь Область плановых потерь Время Продукты 148
Управление изменениями Стратегия «Жесткие сроки» Ресурсы Область недопустимых потерь Область нежелательных потерь Область допустимых потерь Область плановых потерь Время Продукты 149
Управление изменениями Манипулирование ресурсами, сроками, продуктами Сроки ● Изменение сроков завершения отдельных работ в пределах вех ● Смещение вех проекта ● Увеличение общего срока завершения проекта Ресурсы: ● Увеличение интенсивности работ ● Замена исполнителя ● Материальное стимулирование ● Привлечение дополнительных исполнителей ● Привлечение субподрядчиков Продукты ● Изменение качества продукта ● Замена продукта ● Исключение продукта 150
Управление изменениями Манипулирование ресурсами Привлечение субподрядчиков: ● Заключается в привлечении сторонних организаций для выполнения определенных работ в проекте. ● Выполняется когда желаемые результаты не могут быть достигнуты с использованием только внутренних ресурсов компании. ● Находится в области нежелательных потерь, поскольку затраты связанные с привлечением субподрядчика значительно влияют на расходную часть бюджета проекта. ● Преимущества - возможно сокращение общей продолжительности проекта, вследствие привлечения субподрядчиков, обладающих более высокой квалификацией, чем это было запланировано, возможность освободить собственные ресурсы ● Недостатки - увеличение стоимости проекта, риск снижения качества продукта (привлечение неизвестного компании субподрядчика) и снижение управляемости проекта. 151
Управление изменениями Манипулирование сроками Смещение вех: ● Заключается в назначении для вехи новой даты. ● Применяется в случае, когда вследствие объективных причин рабочая группа не может закончить работу в намеченный срок, и при этом веха проекта не привязана к событию, которое нельзя перенести, а общая продолжительность проекта не увеличивается. ● Находится в области допустимых потерь, поскольку смещение вехи не оказывает значительного влияния на проект, не приводит к значительным финансовым потерям (удорожание проекта, привлечение новых ресурсов в проект и т. д. ). ● Преимущества - работы ведутся в обычном режиме, перегрузки ресурсов при этом не происходит. ● Недостатки - изменение в худшую сторону имиджа Компании, неполучение премии. 152
Управление изменениями Манипулирование характеристиками продукта Снижение качества продукта: ● Заключается в снижении качественных характеристик продукта проекта. ● Применяется когда заказчик в контракте не установил жестких требований к качественным характеристикам продукта/услуги, но заказчику необходимо уложиться в запланированные сроки или/и не допустить перерасхода бюджетных средств проекта, а исполнитель не может поставлять продукт/услугу требуемого заказчиком уровня качества. ● Находится в области плановых потерь, поскольку возможность определенного снижения качества продукта проекта изначально заложена (должна быть!) в контракте (возможно в неявной форме). ● Преимущества – возможность квалифицированных ресурсов. ● Недостаток - возможен конфликт с Заказчиком. использования менее 153
Корпоративный стандарт управления проектами Раздел 12. Другие разделы корпоративного стандарта 12. 1. Управление поставками и контрактами 12. 2. Управление коммуникациями 12. 3. Обеспечение охраны труда и промышленная безопасность 12. 4. Обеспечение охраны окружающей среды 12. 5. Обеспечение работы с претензиями 12. 6. Управление качеством в проекте 157
Управление поставками и контрактами Процессы и функции Концепция управления контрактами ● Маркетинг (источники информации, рекла ма) ● Стратегия (фирмызаказчика, проекта, критерии и методы выбора) ● Предметная область (работы, потребность в ресурсах и их спецификация) ● Возможные источники и условия рынка (внутренние, внешние) ● Ограничения ● Анализ альтернатив (поставщики, качество, стоимость, риски) Планирование поставок и контрактов Организация и подготовка контрактов ● Определение потребности (работы и услуги, трудовые ресурсы, поставки, покупки) ● Источники информации (внутренние, внешние, недостающая информация) ● Выбор метода обеспечения (реклама, приглашение, переговоры, приобретение) ● Определение типов контрактов ● Определение перечня контрактов и распределение ответственности ● График заключения контрактов ● Подготовка тендерной документации ● Приглашение на торги ● Ответы на предложения ● Проведение торгов и выбор претендентов ● Анализ и оценка предложений ● Отбор кандидатов ● Работа по отвергнутым предложениям ● Проведение переговоров ● Заключение контрактов Контроль и регулирование контрактов ● Учет выполнения работ по контракту ● Представление отчетности о выполнении контрактов и счетов ● Контроль и анализ выполнения контрактов ● Финансовый контроль контрактов ● Урегулирование споров и разногласий ● Формирование заявок на изменения, документирование, корректировка контрактов и доведение информации до участников Завершение контрактов ● Формирование архива контрактной документации ● Заключительный анализ и оценка эффективности обеспечения проекта ● Заключительный отчет по управлению контрактами в проекте ● Извлеченные уроки 158
Управление поставками и контрактами Современные принципы и технологии Принципы современного контрактинга q Теоретической базой современного контрактинга является институциональная экономика, главной причиной возникновения трансакционных издержек называющая «неопределенность» q Источником неопределенности являются поведение участников проекта и их взаимоотношения: «ограниченная рациональность» , «оппортунистическое поведение» , «специфичность активов» (неравноправие позиций). q Факторы неопределенности рассматриваются как специфические проектные риски q Общее решение: контракт должен являться средством гармонизации интересов сторон q Тип контракта выбирается в зависимости от сложности проекта, разделения ответственности за риски, природы неопределенности (источников рисков) Виды контрактов Максимальный риск заказчика Максимальный риск подрядчика Твердая цена Время и материалы Затраты плюс вознаграждение Твердая цена плюс стимулирующая оплата Затраты с ограничением «сверху» Затраты плюс наценка Твердая цена с возможностью пересмотра в диапазоне Затраты плюс процент от затрат 159
Управление поставками и контрактами Стили контрактного менеджмента (1) СОТРУДНИЧЕСТВО ПРОТИВОСТОЯНИЕ Наиболее подходящий метод в изменяющихся условиях, когда требуется определенная гибкость. Преимущества особенно очевидны в долговременном плане. -Совместная оценка рисков -Возможна совместная работа по управлению рисками -Обмен информацией -Совместная работа над общими задачами -Уменьшение расходов на закупки и увеличение прибыли поставщика Подходящий метод в условиях проведения переговоров или если имеет место неудовлетворительное исполнение контракта -Конфликтные взаимоотношения покупателя / поставщика - «Ваши риски» - «Ваши проблемы» -Защита информации -Одна сторона выигрывает за счет другой ПАССИВНОЕ УЧАСТИЕ АКТИВНОЕ УЧАСТИЕ Наиболее подходящий метод в случае многих пользователей, когда нет одного явно выраженного конечного получателя. Функции менеджмента ограничены координацией. -Принятие решений за поставщиком -Мониторинг общего состояния дел или управление по отклонениям -Оценка результатов по четким заранее оговоренным параметрам Подходящий метод в условиях неудовлетворительного исполнения контракта. Менеджер по контракту исполняет роль своего рода «фильтра» по контролю требований заказчика. -Требуется много усилий со стороны менеджера -Им же принимаются ключевые решения -Действия поставщиков управляются и контролируются 160
Управление поставками и контрактами Стили контрактного менеджмента (2) СОЗЕРЦАТЕЛЬНЫЙ Стабильный процесс. -Стандартный мониторинг в терминах времени, стоимости и качества -Отчет вышестоящему руководству ОБЩЕДОСТУПНЫЙ, ОТКРЫТЫЙ Для контрактов в изменяющемся бизнес окружении. -Полная открытость и доступ к информации -Открытие для поставщиков информации по ценам, стоимости, бюджету -Открытое делопроизводство, включая бух. учет МНОГОУРОВНЕВЫЙ Большие, сложные контракты -Взаимоотношения больше чем на одном уровне и зачастую с несколькими контрактами УПРЕЖДАЮЩИЙ Для сложных, больших по объему закупок. -Прогнозирование, реагирование на отклонения, упреждение сбоев -Снижение потерь -Установление тесных рабочих отношений с поставщиками ОФИЦИАЛЬНЫЙ, ФОРМАЛЬНЫЙ Для стабильных услуг, не критичного бизнеса. -Нежелание сторонами раскрывать стоимость или бюджет. -Нет тесных рабочих отношений ПРОСТОЙ Небольшие, простые контракты. -Одноуровневые взаимоотношения 161
Управление поставками и контрактами Технология Governance Contracting. TM (по Дэвиду Домбкинсу) Выражение первоначального интереса сторон Запрос на Предложение • Проверка зрелости, компетентности и деловой культуры потенциальных Исполнителей • Информирование потенциальных Исполнителей о намерениях Заказчика. Окончательный выбор лучшего Предложения Обсуждение Бизнес плана • Обсуждение бизнес-планов в форме совместных проектных мастерских с каждым из претендентов • Окончательная оценка уровня компетентности и деловой культуры претендентов • Предложение претендентам разработать Бизнес- план проекта (ТКП) • Предварительная оценка способности претендента применить к конкретному проекту свои возможности, подтверждённые на предыдущем этапе Заключительные переговоры • Выбранный Исполнитель и Заказчик совместно работают над Бизнес планом для заключения контракта • Достижение соглашений о взаимной ответственности, как основы для создания общих проектных команд и органов управления • Претенденты получают возможность модифицировать свои бизнес планы • Производится выбор лучшего из представленных предложений 162
Управление поставками и контрактами Пример оценки предложения (по срокам поставки) Срок поставки Досрочная поставка Есть возможность Требуется склад досрочного (изменения в использования графике работ) Возможно повышение цены Настаивать на снижении цены Цена предложения до коррекции на отклонения в графике поставок Поставка в рамках предусмотренных сроков Поставка с задержкой Самый ранний Позднее самого предусмотренный раннего предусмотсрок ренного срока Не влияет на цену Настаивать на снижении цены + Экономия за счет более ранней/поздней поставки + Складирование/страхование Отклонить предложение Цена предложения = после коррекции 163
Управление поставками и контрактами Аудит контракта (по Родни Тернеру) Не слишком ли много работ нам навязали? Выгодно ли? Не слишком ли много мы уступили в переговорах? Нужно? Хотим? Можем? Решение об участии в тендере • • Обсуждение условий контракта Подготовка к тендеру Стратегия и маркетинг Доступные ресурсы и технологии Соотношение costbenefits • • • Все ли работы/затраты фиксируются? Планирование и старт проекта • Стратегия и маркетинг • Тактика ведения переговоров • Усовершенствования • Контроль изменений Стратегия и маркетинг Ресурсы и технологии Коммерческая сторона Календарный план Риски Укладываемся в смету? Выполнение контрактных обязательств • Рабочая сила, материалы и оборудование • Субподряд • Календарный план • Выставление счетов и финансирование • Стартовое совещание • Рассмотрение заявок • Корректировка базовых данных • Контроль изменений Всё ли учтено в финальных расчетах? Прогноз завершения Окончание проекта и закрытие контракта • Передача объекта • Получение оплаты • Расчеты с персоналом и субподрядом • Аудит и анализ результатов • Прогноз времени и затрат до завершения • Сравнение с базовым планом • Управление отклонениями 164
Управление поставками и контрактами Обеспечение баланса интересов и конструктивного партнерства сторон Аспекты внедрения Технические аспекты Проект, исполнение Продукты, услуги, решения Управление проектом и контрактами Координация, расстановка сил, баланс интересов Бизнес аспекты Правовые аспекты Цели, зависимости, финансы, стоимость, сметы, мотивы Управление, соответствие, законы, непредвиденные обстоятельства Источник: Helena Haapio «Contracting for Project Success and Problem Prevention» . The Proceeding of 20 th IPMA World Congress on Project Management 165
Управление поставками и контрактами Профилактическая юридическая самозащита контрактора В-третьих, последствия … Во-вторых, эффекты … Во-первых, причины … Урегулирование конфликтов, судебных исков, минимизация потерь ● Контрактинг в части разрешения споров Минимизация проблем и вредных эффектов ● Контрактинг в части рисков и непредвиденных обстоятельств Исключение причин проблем и ошибок ● Контрактинг в части исполнения работ Источник: Helena Haapio «Contracting for Project Success and Problem Prevention» . The Proceeding of 20 th IPMA World Congress on Project Management 166
Управление поставками и контрактами «Hand Tool» для повышения качества контрактов Когда? Как? Когда? Где? Как? Что если (не)? . . Что? Доставка (исполнение) Оплата Кто / В какой роли? Чьи риски? Чьи расходы? Источник: Helena Haapio «Contracting for Project Success and Problem Prevention» . The Proceeding of 20 th IPMA World Congress on Project Management 167
Управление коммуникациями Процессы и функции Концепция коммуникаций в проекте ● Определение коммуникационной стратегии (цели, задачи, ограничения, общие требования) ● Определение базовой проектной документации ● Определение участников проекта (заказчик, руководство организации, команда проекта, исполнители и пр. ) ● Формирование требований к коммуникациям ● Оценка альтернатив и выбор коммуникационных технологий ● Утверждение коммуникационной стратегии Планирование коммуникаций ● Построение логикоинформационной схемы проекта ● Определение информационных потребностей участников ● Определение методов и средств работы с информацией ● Определение видов, форм и содержания документов ● Разработка регламентов формирования и распределения информации ● Разработка средств технического обеспечения коммуникаций Распределение информации и анализ коммуникаций Завершение работы коммуникаций в проекте ● Организация распределения информации в проекте ● Анализ функционирования системы коммуникаций ● Формирование заявок на изменения системы коммуникаций, корректировка регламентов, модификация средств технической поддержки ● Формирование архива проектной документации ● Заключительный анализ и оценка эффективности коммуникаций в проекте ● Извлеченные уроки ● Принятие решения о дальнейшем использовании средств коммуникаций проекта 168
Управление коммуникациями PR проекта Роль PR в период кризиса 1. Имидж 2. Паблисити 3. Информация Необходимость «сохранить лицо» в условиях кризиса проекта Компенсация репутационного ущерба в одном проекте за счет других хороших новостей Донесение точной информации в легкодоступном формате до целевой аудитории Что нужно уметь и знать заранее: • Как преподносить плохие вести? Четко объяснить что происходит и что предпринимается для решения проблемы, утаивание плохих новостей приводит к недоверию и подозрениям • Как отвечать на вопросы? СТОП – Сообщить о вопросе всем, Теперь подумать, Ответить по существу без лишних деталей, Проверить реакцию аудитории • Как справиться со СМИ? Причины обращения к СМИ (или СМИ к нам), выбор дискуссионного поля, выбор места интервью, выбор СМИ, подготовка к интервью, тактика проведения интервью, разбор полетов после интервью
Управление коммуникациями Коммуникации, или искусство сообщать плохие новости Коммуникации с командой 1. Ничего не скрывайте от команды Коммуникации с клиентом 2. Имейте в виду, что команда может что-то скрывать от вас 1. Честно расскажите о том, что случилось, не пытайтесь ничего скрыть или ввести клиента в заблуждение 3. Помните про стандартную реакцию на плохие новости (ОГПОП) – отрицание, гнев, попытка найти решение, отчаяние, принятие 2. Сообщите, какие меры вы предприняли, чтобы идентифицировать проблему и исправить положение 4. Не оставляйте команду наедине с плохой новостью – организуйте дискуссию, мозговой штурм, чтобы люди смогли сжиться с новой ситуацией 3. Вовлеките клиента в обсуждение, сформируйте реалистичные ожидания 4. Старайтесь обсуждать действия, а не решения. Если решение окажется ошибочным (не полным) доверие будет подорвано окончательно 5. Помните про ОГПОП. Запланируйте перерыв (на кофе), но не дайте им сбежать и начать распространять панику
Управление коммуникациями Техника коммуникаций 1. Не перебивайте собеседника 11. Будьте креативны 2. Излагайте факты, а не мнения 3. Не переходите на личности 12. Исходите из того, что решение проблемы существует 4. Просите разъяснений, если что-то не понятно 13. Не спешите идти на уступки, решайте проблему 5. Будьте точны и конкретны, избегайте обобщений 14. Подумайте о последствиях, которые наступят, если конфликт не будет разрешен 6. Позвольте всем высказаться 15. Будьте справедливы 7. Придерживайтесь главной темы, не отвлекайтесь на второстепенные темы 16. Избегайте взаимных обвинений 8. Ищите причины кризиса, а не виновных 18. Устанавливайте реалистичные сроки 9. Стремитесь к позитивному результату 19. Ведите протокол заседания 10. Будьте реалистами в решениях 20. Достигайте консенсуса 17. Будьте позитивны
Управление коммуникациями Техника переговоров Переговоры – средство разрешения разногласий между заинтересованными сторонами и достижения взаимовыгодного или приемлемого решения, результатом переговоров может быть консенсус, компромисс или волевое решение Этапы переговорного цикла 1. Планирование: Определите цели, приоритеты и рубежи (крайняя дата, максимальная цена, минимальный объем); определите переговорщиков (принимающие решения, влияющие) 2. Исследование: Соберите всю необходимую информацию; убедитесь что все переговорщики понимают предмет обсуждения одинаково 3. Предложение: Обозначьте начальную позицию; не раскрывайте все карты сразу - оставьте место для маневра 4. Торги: Детально обсудите все позиции; ничего не отдавайте партнеру по переговорам, не получив за это что-либо взамен 5. Завершение: Зафиксируйте достигнутые договоренности в однозначно трактуемых формулировках; проявляйте твердость в отстаивании полученных преимуществ
Управление коммуникациями Проблемы и решения Негативные последствия плохих коммуникаций в проекте ● ● Потеря времени - на поиск необходимых документов, на переключение интерфейсов, поиск документов в нескольких системах Простои из-за недоступной, неактуальной, не утвержденной документации, из-за ожидания указаний Паузы в работе из-за перемещение бумажных копий между разработчиками и исполнителями Непроизводительная трата времени из-за повторного исполнения документов (распоряжений ) Решения на уровне документооборота ● ● ● Управление договорами § Создание электронной версии договора § Рассылка договора на согласование § Формирование претензий по исполнению договоров Управление распорядительными документами § Приказы § Распоряжения § Внутренние нормативные документы (положения, правила) Управление корреспонденцией § Внутренней - служебные записки § Внешней - входящие/исходящие письма Электронный архив Поддержка процесса перевода документов Решения на уровне средств связи ● ● ● Виртуальный проектный офис Спутниковые каналы связи Электронная почта и др. Будут более подробно рассмотрены на примерах конкретных проектов (Часть 4) 173
Управление качеством в проекте Процессы и функции Концепция качества в проекте ● Формирование политики и стратегия качества (цели и задачи, критерии качества, стандарты и правила) ● Определение принципов обеспечения качества процессов управления (адекватность и своевременность управленческих решений, соблюдение процедур принятия решений) ● Определение принципов обеспечения качества продукта проекта ● Утверждение концепции качества Планирование качества управления проектом ● Формирование Плана управления проектом, раздел «Обеспечение качества» (план по качеству) ● Формирование плана аудиторских проверок проекта ● Разработка формы анкет мониторинга и отчетности, адаптированных для данного проекта Организация, осуществление и анализ состояния контроля качества ● Организация, информационная и техническая поддержка контроля качества ● Проведение запланированных мероприятий в форме аудита, мониторинга и экспертизы проекта ● Анализ отклонений качества ● Корректирующие действия по обеспечению качества в области процессов управления и в области продукта ● Решение о приемке промежуточных результатов Завершение управления качеством ● Сводная оценка качества результатов и процессов управления ● Решение о завершающей приемке ● Список замечаний и претензий по качеству ● Разрешение спорных вопросов и конфликтов ● Оформление документации и архива ● Извлеченные уроки 177
Управление качеством в проекте Цикл менеджмента процесса Деминга / Шухарта / Ишикавы Act - Действие Предпринять соответствующее действие Проверка эффектов реализации Check - Проверка Plan - План Определение целей и задач Определение методов достижения целей Участие в образовании и обучении Внедрение рабочего процесса Do - Выполнение 178
Качество процессов управления проектами Аудит проекта 179
Качество процессов управления проектами Мониторинг проекта Процессы мониторинга ● Сбор необходимой информации по мере ее появления в ходе проекта ● Хранение всей необходимой информации по проекту ● Представление этой информации, как в интегральной, так и в детальной форме в соответствии с запросами пользователей ● Отображение соответствия плана и фактических событий проекта Анкета мониторинга 180
Качество процессов управления проектами Мониторинг статуса качества процессов управления Управление коммуникациями Управление рисками Управление содержанием и границами Проектное планирование Управление качеством Финансовое и контрактное управление Управление ресурсами Управление изменениями ИНТЕГРАЛЬНАЯ ОЦЕНКА ПО ПРОЕКТУ 1 3 5 Требует немедленного вмешательства 7 9 Держать на контроле 11 13 15 Не требует специального внимания 181
Качество процессов управления проектами Экспертиза проекта Источники информации: ● Формализованные данные процедур аудита и мониторинга проекта. ● Консультации и собеседования Экспертное заключение: ● Рекомендации по преодолению проблем ● Тиражирование положительного опыта 182
Нужно ли вашей организации на пятый уровень зрелости? Служба управления проектами и служба управления качеством Генеральный директор Зам. Генерального директора Служба управления качеством Служба управления проектами ● Методология обеспечения качества ● Контроль качества ● Аудит проектов ● Методология управления проектами ● Мониторинг и экспертиза проектов ● Управление проектами ● Техническая поддержка управления проектами Проблемы борьбы за качество управления проектами: ● Значительная стоимость работ по созданию и внедрению процедур, обучению персонала ● Увеличение «непроизводительных» трудозатрат в проектах ● Негативная реакция «регламентируемого» персонала 183
Корпоративный стандарт управления проектами 184
Скачать презентацию www ibs ru Часть 3 Корпоративный стандарт управления
Часть 3. Корпоративный стандарт управления проектами (20 часов).ppt