Корпоративная методология управления проектами: основные документы. Внедрение программного продукта
Разработка Устава проекта – это процесс разработки документа, который формально
санкционирует проект или фазу, и документирования первоначальных требований,
удовлетворяющих потребностям и ожиданиям заинтересованных сторон проекта. Он
устанавливает партнерство между исполняющей организацией и организацией,
подавшей заявку (или заказчиком, в случае внешних проектов). Утвержденный Устав
проекта формально инициирует проект. Менеджер проекта определяется или
назначается сразу, как только это становится возможным, предпочтительно во время
разработки Устава проекта и обязательно до начала планирования. Рекомендуется,
чтобы менеджер проекта участвовал в разработке Устава проекта, так как данный
документ наделяет менеджера проекта полномочиями использовать ресурсы для
выполнения проекта.
Санкционирование проектов производится внешним по отношению к проекту
лицом или лицами, такими как спонсор, офис управления проектами (Project
Management Office, PMO) или комитет по управлению портфелями. Уровень
инициатора или спонсора проекта должен быть достаточным для финансирования
проекта. Они либо сами разрабатывают Устав проекта, либо делегируют эту
обязанность менеджеру проекта. Подпись инициатора на Уставе санкционирует
проект. Санкционирование проектов обуславливается внутренними бизнес-
потребностями или влиянием извне. Обычно это приводит к подготовке анализа
потребностей, экономического обоснования или описания ситуации, которую будет
решать проект. Написание Устава проекта связывает проект со стратегией и текущей
деятельностью организации.
На рис. 4-2 показаны входы, инструменты и методы, а также выходы для данного
процесса, а на рис. 4-3 представлена блок-схема данных.
Рис. 4-2. Разработка Устава проекта: входы, инструменты, методы и выходы
Рис. 4-3. Блок-схема данных при разработке Устава проекта
4.1.1 Разработка Устава проекта: входы
1 Описание работ по проекту
Описание работ (Statement of work, SOW) – это словесное описание продуктов или
услуг, которые должен произвести проект.
Перечень работ отражает:
Бизнес-потребность.
Описание содержания продукта.
Стратегический план.
2 Экономическое обоснование
Экономическое обоснование или подобный документ предоставляет необходимую с
точки зрения бизнеса информацию, позволяющую определить, стоит ли проект требуемых инвестиций.
Экономическое обоснование создается как результат действия одного или нескольких из следующих факторов:
Требования
Потребность организации
Требования заказчика
Технологический
Правовые требования
Экологические
Социальные
3 Контракт
Контракт является входом, если проект выполняется для внешнего заказчика.
4 Факторы среды предприятия
Факторы среды предприятия, которые могут оказывать влияние на процесс разработки
Устава проекта, включают в себя среди прочего:
Государственные и промышленные стандарты;
Инфраструктуру организации;
Ситуацию на рынке.
5 Активы процессов организации
Активы процессов организации, которые могут оказывать влияние на процесс
разработки Устава проекта, включают в себя среди прочего:
Стандартные процессы организации, правила и описания типовых процессов для
использования в организации;
Шаблоны (например, шаблон Устава проекта);
Историческую информацию и базу усвоенных уроков.
4.1.2.Разработка Устава проекта: инструменты и методы
1 Экспертные оценки
Применяются в отношении любых технических и управленческих деталей. Такие
экспертизы проводятся любым лицом или группой лиц, обладающих специальными
знаниями или подготовкой, и доступны из множества источников, включая следующие:
Другие подразделения в рамках организации;
Консультанты;
Заинтересованные стороны проекта, в том числе заказчики или спонсоры;
Профессиональные и технические ассоциации;
Отраслевые объединения;
Эксперты по отдельным вопросам;
Офис управления проектами (Project management office, PMO).
Данная статья предназначена для новичков в управлении проектами. Если вы знаете что именно из себя представляет устав проекта, то можете смело пропускать данную статью.
В настоящее время, большинство руководителей проектов знают (по крайней мере, приблизительно) что такое устав проекта. Попробуем разобраться, что же это такое в точности и зачем оно нужно.
Если вы работаете в консалтинговой компании то, скорее всего, вы не сталкиваетесь с необходимостью формирования устава проекта. Наиболее вероятно, что у вас в компании инициация проекта происходит следующим образом:
1. Вы, как руководитель проектов, получили некое сообщение о том, что есть возможность выполнить проект. Это может быть RFP (запрос на предложение), которое вам передали из отдела продаж с просьбой помочь в подготовке коммерческого предложения, а может быть приглашение, пришедшее от вашего руководителя, с назначением на новый проект. В любом случае, вы знаете, что проект начинается.
2. Подготавливается контракт на проект. Вы, проработав примерный список работ и прикинув стоимость, совместно с руководителем заключаете контракт с Заказчиком.
3. Вы начинаете работу.
В данном случае, роль устава проекта выполняет контракт. Он наделяет вас полномочиями, и он же диктует вам рамки проекта. Согласно контракту вы выполняете и оцениваете работу.
В случае, если проект внутренний, необходимо писать устав проекта. Для чего? Причин множество.
Первая и самая простая - устав является формальным объявлением начала проекта. Как вы сможете оценить, сколько длится проект, если вы не знаете, когда именно он начался? С даты подписания устава отсчитывается длительность проекта.
Вторая цель - закрепление полномочий за руководителем проекта. Проект может стартовать, но как вы будете руководить им, если у вас нет полномочий? Обычно, внутри компании, устав проекта подписывается значимым лицом (генеральным директором или его заместителем). Таким образом, получив устав проекта, менеджер проекта формально объявляет, что данный проект это не его личная прихоть, за ним стоит руководитель организации, который считает необходимым выполнить этот проект и для достижения этой цели предоставляет руководителю проекта определенные полномочия.
Третья цель устава проекта - зафиксировать первоначальные цели проекта. Ведь в процессе выполнения проекта, его цели могут меняться, в связи с чем, будут изменяться и сроки. В этом случае, руководитель проекта имеет возможность показать взаимосвязь между изменением целей и изменением сроков.
Четвертая цель устава проекта озвучить руководству в общих чертах риски, связанные с возникновением проекта и с работами на проекте. Когда запускается новый проект, возникают риски с ним связанные. Эти риски опасны не только для самого проекта, но могут быть опасны и для организации в целом. Соответственно, все начальные риски, которые вы идентифицировали, помещаются в устав проекта и озвучиваются руководству.
Часто, в устав проекта добавляют положение о создании управляющего комитета, но это уже индивидуально. Если положение об управляющем комитете не добавлено в устав, его можно включить в другой документ.
Часто устав проекта называют контрактом для внутренних проектов. Это неверно, т.к. устав проекта не служит для фиксирования каких либо договоренностей между сторонами проекта. Он служит только для тех целей, которые я озвучил выше. Не нужно стараться сделать из устава проекта что-то большее - он для этого не предназначен. Попытки напихать в устав проекта как можно больше информации обычно приводят лишь к увеличению сроков согласования устава и противоречиям в документах.
Составляется устав проекта, обычно руководителем проекта, а утверждается Спонсором проекта и Заказчиком проекта.
Успешных вам проектов!
Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта . Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2 . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: · утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения; · назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; · формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; · вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; · принимать решения о внесении изменений в базовую линию проекта . Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта . Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса - словосочетание, не несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе? Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проектаВ продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных PMI к разработке при управлении проектом:
- Устав проекта (project charter);
- Документ, определяющий содержание проекта (project scope statement (preliminary and detailed);
- План управления проектом (project management plan).
КОРПОРАТИВНЫЙ СТАНДАРТ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
Мы предлагаем рассматривать Положение о КСУП или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт) как документ верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.
Следует заметить, что в практике встречаются и другие трактовки корпоративного стандарта по управлению проектами.
В некоторых компаниях под корпоративным стандартом понимают совокупность документов, регламентирующих и обеспечивающих управление проектами.
В других – для управления проектами разрабатывают несколько корпоративных стандартов одного уровня, регламентирующих различные аспекты управления проектами. Такой подход, к примеру, был принят в отношении инвестиционных проектов в управляющей компании одной из известных финансово-промышленных групп.
Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.
Под корпоративным стандартом обычно понимается один документ. Поэтому подобное название для совокупности документов представляется не вполне корректным и может дезориентировать тех, кто занимается разработкой корпоративной методологии управления проектами.
Разработка нескольких корпоративных стандартов одного уровня для управления теми же инвестиционными проектами может привести к созданию фрагментарной методологии. В этом случае определенные процессы и процедуры управления проектами могут быть пропущены или описаны и регламентированы в разных форматах, разными средствами в соответствие с опытом и субъективными представлениями об управлении проектами, имеющимися о разработчиков документов. Интегрировать несколько разных стандартов в единую методологию будет весьма затруднительно.
Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.
Создавать концепцию целесообразно по той причине, что для успешной разработки и внедрения корпоративной методологии управления проектами необходимо, чтобы собственники и руководители высшего уровня договорились между собой и согласовали свое видение и свои требования и ожидания относительно КСУП. Концепция как раз и создает хорошую основу для согласования позиций и достижения принципиальных договоренностей между лицами, принимающими ключевые решения по управлению проектами в компании.
Предназначение корпоративного стандарта по управлению проекта, по нашему мнению, заключается в том, чтобы описать саму КСУП, принципы ее построения, основные элементы, а также подход к управлению проектами, принятый в компании.
В корпоративный стандарт целесообразно включать следующие разделы:
- Назначение и область применения стандарта
- Нормативные ссылки
- Определения терминов, обозначения и сокращения
- Принципы организации системы управления проектами в компании
- Классификация проектов компании
- Процессы управления проектами в компании
- Организационная структура управления проектами
- Распределение функций, полномочий и ответственности в рамках системы управления проектами компании (уровни портфеля, программ, проектов)
- Нормативная база управления портфелем, программами и проектами
- Ведение реестра проектов
- Назначение приоритетов проектов
- Документирование и архивирование проектов
- Информационная система управления проектами
- Порядок внесения изменений в стандарт
- Приложения (шаблоны основных рабочих документов).
УСТАВ ПРОЕКТА (PROJECT CHARTER)
Устав проекта (рroject charter) – один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI – PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.
Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:
- заявку на открытие проекта;
- приказ на открытие проекта;
- некий аналог положения о подразделении (цели, организационная структура управления проектом, распределение ролей и ответственности среди членов проектной команды);
- техническое задание менеджеру проекта от руководства или заказчика;
- обоснование проекта;
- аналог плана управления проектом;
- если по проекту заключается контракт с внешним заказчиком/исполнителем, то он полностью заменяет Устав.
Наиболее удачная трактовка Устава проекта, по нашему мнению, дана в новой редакции PMBOK от 2004 года. В отличие предыдущих трактовок данный документ, действие данного документа не ограничивается фазой инициации проекта. Изменение предназначения Устава заключается в том, что он должен обеспечивать интеграцию проекта, т.е. согласованность действий всех участников на всех этапах проекта.
Предназначение, содержание и порядок разработки и изменений Устава проекта в соответствие с новой редакции PMBOK от 2004 года описаны ниже. Примеры структур Уставов проектов из практики разных компаний приведены в Приложении к статье.
Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:
- документирование бизнес-потребностей (проблем, возможностей) и общее описание продуктов или услуг, удовлетворяющих данные потребности;
- связи проекта с текущей (операционной) деятельностью организации.
Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)
Кто разрабатывает документ: Устав проекта могут разрабатывать:
- инициатор проекта;
- спонсор проекта;
Кто утверждает документ: Устав проекта может утверждать:
- инициатор проекта;
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Лицо, утверждающее Устав проекта, должно иметь полномочия по принятию основных решений по проекту, включая его финансирование.
- контракт;
- Бизнес-потребности или требования к продукту, который будет создан в рамках проекта;
- Цель проекта или основание для разработки проекта (justification);
- Потребности и ожидания заинтересованных лиц (stakeholders);
- Укрупненное расписание контрольных событий;
- Влияние заинтересованных лиц на проект;
- Распределение функций (functional organizations);
- Предположения, связанные с внешним окружением и внутренней организационной средой;
- Ограничения, связанные с внешним окружением и внутренней организационной средой;
- Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI);
- Укрупненный бюджет.
Порядок изменений документа: Команда проекта поддерживает Устав проекта в актуальном состоянии, получает обратную связь от участников проекта о необходимых улучшениях документа, контролирует изменения и выпускает релизы утвержденного документа.
ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)
Ниже описано предназначение, содержание и порядок разработки и изменений Документа, определяющего содержание проекта, в соответствие с новой редакции PMBOK от 2004 года. В этом и в следующих разделах статьи использованы оригинальные английские термины, т.к. использование их русских аналогов, как заметил один из моих коллег, «очень часто ведет в дебри».
Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:
- Характеристики и рамки проекта;
- Требования к продуктам и услугам, связанным с проектом.
Когда разрабатывается документ: После утверждения Устава проекта.
Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:
- менеджер проекта или команда проекта;
- представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта.
Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Входы (исходные данные) для разработки документа:
- Устав проекта;
- документ определения работ (Statement of work);
- факторы внешнего окружения и организационной среды;
- организационные активы (Organizational process assets).
- Цели проекта и цели предметной области проекта;
- Требования и характеристики продукта или услуги;
- Рамки проекта;
- Проектные решения (deliverables);
- Критерии приемки продукта;
- Проектные ограничения;
- Проектные предположения;
- Организация проекта на начальной стадии;
- Идентификация рисков на начальной стадии;
- Расписание контрольных событий;
- Предварительный расчет стоимости (Order of magnitude cost estimate);
- Требования к управлению конфигурацией проекта;
- Согласованные требования (Approval requirements).
Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.
ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)
Ниже описаны предназначение, содержание и порядок разработки и изменений Плана управления проектом, в соответствие с новой редакции PMBOK от 2004 года.
Предназначение документа: На базе Плана управления проектом обеспечивается определение, интеграция и координация всех составных планов проекта. План управления проектом – основное средство о том, как должен выполняться, отслеживаться и контролироваться.
Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.
Кто разрабатывает документ: менеджер проекта или команда проекта с участием других заинтересованных лиц.
Кто утверждает документ: План управления проектом может утверждать:
- спонсор проекта;
- представитель внешней стороны, связанной с проектом.
Входы (исходные данные) для разработки документа:
- Устав проекта;
- Project Scope Statement (preliminary);
- Процессы управления проектом;
- Прогнозы
- Факторы внешнего окружения и организационной среды;
- Организационные активы (Organizational process assets);
- Информация о выполнении работ.
- Процессы, выбранные командой управления проектом;
- Уровень внедрения каждого выбранного процесса, определенный командой управления проектом;
- Описание средств и техник, используемых для выполнения этих процессов;
- Выбранный жизненный цикл проекта и связанные с ним фазы проекта;
- Как выбранные процессы будут использованы для управления конкретным проектом. Включение зависимостей и взаимодействий между этими процессами и необходимых входов и выходов;
- Как будет организовано выполнение работы для достижения целей проекта;
- Как будут осуществляться мониторинг и контроль изменений;
- Как будет осуществляться управление конфигурацией;
- Как будет обеспечиваться интеграция исходных планов (baselines) проекта;
- Потребности в информации и техники коммуникаций между заинтересованными лицами;
- Ключевые управленческие обзоры по содержанию, масштабу, выбору сроков проекта, обращенные к открытым вопросам и предстоящим решениям по проекту.
План управления проектом может суммировать/объединять все отдельные планы проекта или некоторые из них:
- План управления содержанием;
- План управления расписанием;
- План управления стоимостью;
- План управления качеством;
- План улучшений;
- План управления персоналом;
- План управления коммуникациями;
- План управления рисками;
- План управления поставками.
Порядок изменений документа: Изменения Плана управления проекта проходят через процесс Интегрированного управления изменениями и могут быть связаны с модификациями, дополнениями и ревизиями проекта. При этом статус Плана меняется на обновленный (updated).
Ниже приведена схема формирования рассмотренных рабочих документов проекта на разных этапах его жизненного цикла. Все использованные английские термины были раскрыты ранее, за исключением одного – Subsidiary Plans. Под этим термином понимаются отдельные планы, которые могут обобщаться или объединяться в Плане управления проектом (СМ. предыдущий раздел).
А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты – [email protected] .
Приложение
ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ
Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).
Примечание: В материалах данной компании специально подчеркивается, что данный документ не является Планом проекта, хотя включает в себя даты, к которым нужно стремиться в рамках проекта.
Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).
СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация
Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)
СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.
Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор)
СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ
В соответствии с предлагаемым подходом бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается "на пересечении" соответствующих значений двух обозначенных факторов.
Использование матрицы структурирования выгод начинается с определения характера воздействия на бизнес каждой из них. Определены три типа воздействия.
- Создание новых возможностей : функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.
- :функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.
- Отказ от операций :информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.
| ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС | ||||
|---|---|---|---|---|
| Создание новых возможностей | Повышение эффективности операций | Отказ от операций | ||
| СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ | Финансовые | |||
| Количественные | ||||
| Измеримые | ||||
| Качественные | ||||
После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые (качественные), измеримые, количественные, финансовые.
- Качественные : выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.
- Измеримые :выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.
- Количественные :аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.
- Финансовые :это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR , периода окупаемости.
Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории - наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы ( TCO ), рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта.
Формирование бизнес-цели проекта
Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).
Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.
Бизнес-цель должна быть достаточно веской, чтобы организация решилась перейти к разработке устава проекта, документа, в соответствии с лучшими практиками инициирующего выполнение проекта. В качестве инструмента, позволяющего определить необходимость реализации проекта, может быть использовано ТЭО , или бизнес-кейс, проекта.
Разработка устава проекта
Устав проекта - это инструмент, который формально авторизует проект и является звеном, соединяющим предстоящий проект с текущей работой организации. Данный документ обычно отражает ситуацию со стороны организации-заказчика, выпускается руководителем, внешним по отношению к проекту, и назначает менеджера проекта, наделяя его полномочиями на использование в проекте ресурсов организации. Это особенно актуально в функционально-ориентированных и матричных организациях , т.е. в тех компаниях, где менеджеры не имеют непосредственной власти над членами проектной команды и другими ресурсами, но несут ответственность за выполнение проекта. Для того чтобы устав имел силу в подобной ситуации, издающий его руководитель, или спонсор проекта , должен находиться на том уровне, который подразумевает наличие контроля над ресурсами. Часто датой начала проекта считается день, следующий за подписанием устава.
Процесс разработки устава проекта уже подразумевает, что компания заинтересована в достижении какой-то цели или решении имеющейся проблемы и готова выделять под это ресурсы. Следовательно, со стороны организации-заказчика есть мотив инвестировать средства и ресурсы в генерацию такой информации, которая позволит разработать корректный устав проекта . К информации, имеющей ключевое значение для составления устава, относятся:
- стратегические и тактические цели организации-заказчика;
- формулировка требований организации-заказчика;
- ТЭО ;
- контракт;
- внутрикорпоративная методология управления проектами и соответствующие политики.
Решение о выполнении проекта - итог процесса отбора проектов, основанного на информации, которая изложена в вышеуказанных документах. Таким образом, крайне важно давать прямую ссылку в соответствующих разделах устава на них с тем, чтобы придать уставу больший вес .
В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.
| № | Раздел | Пояснения |
|---|---|---|
| 1 . | Название проекта | Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания |
| 2 . | Бизнес-причина возникновения проекта | Производственная необходимость, или самое общее описание проекта и требований к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте |
| 3 . | Бизнес-цель | Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см. раздел "Формирование бизнес-цели проекта " |
| 4 . | Требования , удовлетворяющие потребности , пожелания и ожидания заказчика , спонсора и других участников проекта | Видение организацией-заказчиком, как правило, высокоуровневое, способов достижения поставленной бизнес-цели или решения существующей проблемы. Проект считается успешным, если ожидания заказчика и участников проекта оказались выполненными, следовательно, к моменту формирования устава проекта его участники должны быть идентифицированы. Все задокументированные в уставе требования должны быть учтены при выполнении стоимостной оценки проекта |
| 5 . | Расписание основных контрольных событий | На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта , принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств |
| 6 . | Участники проекта | Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел "Идентификация участников проекта" |
| 7 . | Окружение проекта | Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов, действующих в окружении проекта ; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) |
| 8 . | Допущения относительно организации и окружения, а также внешние допущения | Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений:
|
| 9 . | Ограничения относительно организации и окружения, а также внешние ограничения | Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ . Пример ограничений проекта:
|
| 10 . | Объем денежных средств, выделенных на достижение бизнес-цели | На данном этапе указывается сумма средств, которую организация-заказчик готова выделить на достижение сформулированной бизнес-цели проекта . Указанная сумма является результатом определения порядка величины и ошибка в оценке может составлять от ~ -20% до +100% |
| 11 . | Назначение руководителей проекта и общее определение полномочий ключевых членов проектной команды: РП , спонсор , координатор | Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта [ , ].
Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2Авторы рекомендуют включать в проект руководителей и двух спонсоров проекта
- по одному от заказчика и исполнителя.
.
Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например:
|
