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

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

1. Вы, как руководитель проектов, получили некое сообщение о том, что есть возможность выполнить проект. Это может быть RFP (запрос на предложение), которое вам передали из отдела продаж с просьбой помочь в подготовке коммерческого предложения, а может быть приглашение, пришедшее от вашего руководителя, с назначением на новый проект. В любом случае, вы знаете, что проект начинается.
2. Подготавливается контракт на проект. Вы, проработав примерный список работ и прикинув стоимость, совместно с руководителем заключаете контракт с Заказчиком.
3. Вы начинаете работу.

В данном случае, роль устава проекта выполняет контракт. Он наделяет вас полномочиями, и он же диктует вам рамки проекта. Согласно контракту вы выполняете и оцениваете работу.
В случае, если проект внутренний, необходимо писать устав проекта. Для чего? Причин множество.

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

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

Успешных вам проектов!

В продолжение первой публикации “Как разработать корпоративную методологию управления проектами”- в данном материале мы рассмотрим основной документ выше упомянутой методологии – Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных 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

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

устав проекта

1. Большакова О.Н., Чусавитина Г.Н. Применение методики pмi для управления рисками проекта по продвижению интернет-магазина: В сборнике: КЛАСТЕРНЫЕ ИНИЦИАТИВЫ В ФОРМИРОВАНИИ ПРОГРЕССИВНОЙ СТРУКТУРЫ НАЦИОНАЛЬНОЙ ЭКОНОМИКИ сборник научных трудов Международной научно-практической конференции, в 2-х томах. Ответственный редактор Горохов А.А.. 2015. С. 64-68.

3. Chusavitina G.N., Zerkina N.N. Cyber extremism preventive measures in training of future teachers: в сборнике: sgem 2015 international multidisciplinary scientific conference on social sciences and arts 2-nd international multidisciplinary scientific conference on social sciences and arts. 2015. С. 275-280.

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

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

На все эти вопросы дает ответ такой курс, как «Управление проектами», в основе которого лежит Microsoft Project - приложение семейства Microsoft Office, позволяющее организовать эффективное планирование и управление проектами. Управление проектами пытается организовать и систематизировать процедуры в проекте, минимизировать риски, с которыми Вы сталкиваетесь. Роль компаний, специализирующихся на разработке и реализации проектов, существенно возросла, а должность и профессия менеджера проекта (Project Manager) стала одной из престижных.

Цель: обеспечить базовую подготовку студентов в области управления проектами. Дать представление о существующих методологиях управления проектами в сфере ИТ и выработать у студентов практические навыки по их применению, чтобы по окончании одного семестра обучения они были в состоянии подготовить и выполнить на качественном уровне свой первый проект. А также, разработать устав проекта и рассмотреть примеры для дальнейшего применения материала при подготовке ИТ-специалистов в процессе работы с ПО MS Project. В данной статье рассмотрим краткие примеры разработки устава проекта с использование Microsoft Project. Устав проекта является документом официального запуска проекта, который готовит будущих руководителем проекта. Как правило, документ согласовывается с управляющим комитетом проекта: спонсором, куратором, клиентом и другими менеджерами . Задачи: зафиксировать причину проекта, определить ключевые параметры проекта - срок, стоимость, качество; назначить роли участников проекта - руководителя проекта и команду проекта; задать порядок управления проектом - общие правила (политики), на основании которых будет вестись управление проектом, права и обязанности всех участников проекта.

Дополнительно в Уставе может быть определено: список основных контрольных событий; ключевые риски проекта - риски определенные на этапе инициации проекта. Детальная информация по рискам детально в плане проекта.

Перейдем к рассмотрению первого примера.

Наименование проекта: разработка сайта «Фабрика сайтов». Дата создания устава проекта: 05.10.2016 г. Основное назначение устава проекта: настоящий устав проекта охватывает работы по разработке и продвижению сайтов «Фабрика сайтов». Миссия компании: компания «Фабрика сайтов» работает над тем, чтобы раскрыть заказчикам новые возможности Интернет-технологий; превратить трудоёмкий и затратный процесс создания сайтов, рекламы в Интернете в доступное и прибыльное для клиента дело. Компания соединяет интересы покупателей и владельцев сайтов, помогая им, найти друг друга в Интернете .

Бизнес-цели заказчика и ожидаемые результаты проекта: создание положительного имиджа компании; реклама и продвижение продукции/услуг компании; маркетинг; реализация продукции/услуг компании; поддержка потребителей и партнеров; информационная поддержка бизнес-процессов компании. Для конкретных сайтов могут ставиться и другие конкретные задачи, но все задачи сайта должны вытекать из экономических целей компании и миссии сайта.

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

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

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

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

Таблица 1

Название задачи

Длительность

Разработка сайта

Предроектное обследование

Определение целей сайта

Создание технического задания

Разработка и создание макета

Создание дизайна сайта

Верстка сайта

Выбор средства разработки

Принятие управленческого решения

Программирование

Наполнение информацией

Расположение сайта в сети Интернет

Тестирование сайта

Создание отчётности

Собрание

Разработка сайта

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

Определение целей сайта

Создание технического задания

Организационная структура проекта. Команда проекта: руководство компании «Фабрика сайтов»; отдел продаж компании «Фабрика сайтов»; работники компании «Фабрика сайтов»; существующие клиенты компании; новые клиенты компании.

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

Риски проекта: сжатые сроки проекта; команда проекта параллельно задействована на других проектах; мы должны выполнить указанный объем и уложиться в ограниченный бюджет проекта. Далее рассмотрим анализ внешней среды проекта. Анализ заинтересованных сторон: потребности, интересы и мнения разных заинтересованных сторон отличаются друг от друга и нередко находятся в противоречии друг с другом; отправная точка клиента расходится с точкой производителя; проблемы работника не совпадают с проблемами руководства; мнения промышленников отличаются от мнений экологов и т.д. Инициатор проекта часто видит только собственные интересы: у технологического эксперта - технические, ученого - научные. Поэтому при разграничении проекта исключительно важно вникнуть в роли и подходы различных заинтересованных сторон. В данном проекте «создание сайта» планирует предпринять все для получения прибыли и ограничения затрат. Цель фирмы связана с развитием, прибыльностью и предоставлением качественных услуг.

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

Далее рассмотрим пример №2. Обоснование проекта. В данном разделе дается краткая информация из принятого бизнес кейса (концепции) проекта для сведения проектной команды. Эта информация важна для определения проекта. Краткое описание проекта: кто заказчик проекта, кто клиент проекта, что является результатом проекта, в одну строку ключевые параметры проекта? Результаты проекта. Для оптимальной реализации перечня представленных услуг и эффективности работы организации было принято решение создать Web-сайт.

Исключено из проекта. Web-сайт не будет предоставлять пользователям личный кабинет на сайте. Начало проекта - 25.03.16. Сумма затрат проекта - 16 400 р. Другие требования. В данный раздел могут быть включены ключевые бизнес-требования к свойствам продукта или специальные требования к организации работ по управлению проектом.

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

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

Таблица 3

Даты проекта и контрольные точки

Название задачи

Длительность

Окончание

Создание сайта

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

Составление договора

Составление ТЗ

Разработка макета

Презентация заказчику

Формирование листа замечаний

Реализация замечаний

Утверждение макета и их подпись

Открытие тестовой площадки

Верстка страниц

Демонстрация заказчику

Формирование листа замечаний

Утверждение верстки

Программирование

Программирование продукта

тестирование заказчиком

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

Данный материал может быть использован при подготовке ИТ-специалистов направлений подготовки «Прикладная информатика», «Бизнес-информатика» и в работе «айтишников» при применении с MS Project.

Библиографическая ссылка

Новикова Т.Б. РАЗРАБОТКА УСТАВА ПРОЕКТА ПО СОЗДАНИЮ САЙТА С ИСПОЛЬЗОВАНИЕМ MS PROJECT // Международный журнал прикладных и фундаментальных исследований. – 2016. – № 12-3. – С. 435-439;
URL: https://applied-research.ru/ru/article/view?id=10856 (дата обращения: 06.04.2019). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

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

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

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

Давайте рассмотрим процесс «Разработка устава проекта» подробнее. На диаграмме ниже изображены входы, инструменты и методы и выходы этого процесса.

Входы процесса «Разработка устава проекта»

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

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

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

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

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

Факторы среды предприятия

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

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

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

Инструменты и методы процесса «Разработка устава проекта»

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

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

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

Выходы процесса «Разработка устава проекта»

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

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

Дмитрий Халдин,

руководитель департамента управления проектами PM Invest Group

Просмотры: 14 258

Транскрипт

1 УТВЕРЖДАЮ декабря 2012 г. УТВЕРЖДАЮ декабря 2012 г. Внедрение программного продукта Устав проекта На 20 стр. Утверждено Приказом от декабря 2012 г. Согласовано: ФИО Должность Подпись Дата Екатеринбург, 2012 г. 1

2 Содержание КРАТКОЕ РЕЗЮМЕ ДЛЯ РУКОВОДСТВА...3 ТЕРМИНОЛОГИЯ... 3 ОБЩИЕ СВЕДЕНИЯ О ПРОЕКТЕ... 4 ТАБЛИЦА 1. ЦЕЛИ И КРИТЕРИИ УСПЕШНОСТИ ПРОЕКТА...4 ГРАНИЦЫ ПРОЕКТА...5 В ПРЕДЕЛАХ ГРАНИЦ ПРОЕКТА:... 5 ЗА ПРЕДЕЛАМИ ОБЪЕМА ПРОЕКТА:... 5 ВЫХОДНАЯ ПРОДУКЦИЯ (РЕЗУЛЬТАТЫ) ПРОЕКТА:...5 ТАБЛИЦА 2. ЗАИНТЕРЕСОВАННЫЕ СТОРОНЫ:... 6 ТАБЛИЦА 3. РАСЧЕТНАЯ СТОИМОСТЬ И ОТНОСИТЕЛЬНАЯ ОЦЕНКА:... 7 ТАБЛИЦА 4. РАСЧЕТНЫЙ ГРАФИК:... 7 ПРОЕКТНЫЕ ДОПУЩЕНИЯ... 8 ПОДХОД К РЕАЛИЗАЦИИ ПРОЕКТА...8 ОРГАНИЗАЦИЯ ПРОЕКТА...11 ТАБЛИЦА 5. УЧАСТНИКИ ПРОЕКТА, ИХ ФУНКЦИИ И ОТВЕТСТВЕННОСТЬ...11 ТАБЛИЦА 6. ЭКСПЕРТЫ РАБОЧИХ ГРУПП...15 УПРАВЛЕНИЕ ПРОЕКТОМ

3 Краткое резюме для руководства Настоящий документ описывает основные положения, процедуры управления и ограничения проекта по внедрению программного продукта: Терминология Заказчик компания Исполнитель компания Проект совместная инициатива Заказчика и Исполнителя по организации работ для достижения целей Проекта. Проектная команда совместная команда руководителей и специалистов для работы в проекте. Стороны Заказчик и Исполнитель. Список требований реестр функциональных и нефункциональных потребностей Заказчика, сформированный в проекте. История - элемент списка требований, который описывается стандартным шаблоном: Я как (роль) могу (действие) для того, чтобы (цель). Описание Истории также должно включать критерии принятия выполнения. История содержит: ID уникальный идентификатор просто порядковый номер. Название краткое описание истории. Важность степень важности данной задачи для Заказчика Например, 10. Или 150. Чем больше значение, тем выше важность. Оценка начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в Баллах. Критерии приемки краткое пояснение того, как завершенная задача будет продемонстрирована, протестирована и принята в конце спринта. По сути, это простой тестовый сценарий типа Сделайте это, сделайте то должно получиться то-то. Баллы - относительно значение, используемое для оценки Истории не связанное конкретно с часами или днями. Оценка проводится в рамках каждого этапа Итерация (Спринт) повторяющийся временной интервал в проекте, в ходе которой создается функциональный рост программного обеспечения и реализуются функциональные требования заказчика. Жестко фиксирован по времени. Длительность одного спринта в проекте принимается длительностью 1 неделя. Совещание по ошибкам/проблемам - встреча, проводимая в конце спринта, в ходе которой определяются сильные и слабые стороны команды проекта в прошедшем спринте, формируются новые знания о процессах реализации проекта. 3

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

5 Границы проекта Проекта имеет следующие границы: В пределах границ проекта: Поставка согласованного количества пользовательских лицензий Системы. Развертывание Системы на аппаратном обеспечении Заказчика. Подготовка сред разработки и тестирования. Проведение анализа бизнес-процессов Заказчика. Настроенные типы документов и моделей для модуля. Подготовка документов и моделей процесса Обучение пользователей Заказчика принципам работы в системе. Настройка справочников. Настройка интеграции с внешними системами со стороны Подготовка пользовательских отчетов. Подготовка пользовательских инструкций. За пределами объема проекта: Приобретение аппаратного обеспечения для надлежащей работы Системы в соответствии с рекомендациями разработчика Системы. Подготовка рекомендаций по совершенствованию процессов Заказчика. Настройка системы на рабочих компьютерах пользователей Заказчика Выходная продукция (результаты) проекта: Выходной продукт (результат) 1: Выходной продукт 2: Выходной продукт 3: 5

6 Выходной продукт 4: Таблица 2. Заинтересованные стороны: Организация (подразделение) Каким образом затронуто / в каком качестве участвует? 6

7 Таблица 3. Расчетная стоимость и относительная оценка: Название этапа Сроки (начала-окончания) Стоимость (руб.) Оценка в Баллах Стоимость услуг составляет рублей. Относительная оценка трудозатрат составляет 317 Баллов. Стоимость неисключительных прав использования системы: Общая длительность проекта оценена в календарных месяца. Таблица 4. Расчетный график: Контрольная точка Дата завершения Выходная продукция (завершенная) 7

8 Проектные допущения Перечисленные ниже допущения являются предположениями, базирующимися на текущем понимании условий проекта и принятые для целей предварительной расчетной оценки задач и графика проекта. Если эти допущения в дальнейшем не подтвердятся, то работы и расчетные оценки проекта должны быть соответствующим образом пересмотрены. Допущение 1: Допущение 2: Допущение 3: Подход к реализации проекта Проект реализуется в соответствии со следующими принципами и положениями. В части «Администрирования»: В проекте назначается руководитель проекта со стороны Заказчика. В проекте назначается менеджер проекта со стороны Исполнителя. Представители руководства со стороны Заказчика и Исполнителя назначаются кураторами проекта. Менеджер проекта формирует проектную команду. Стороны ориентированы на создание мотивированной команды проекта. Основным документами проекта является График реализации проекта, Устав проекта и Список требований, который согласовывается между Сторонами. В части «Планирования и управления» объемом проекта: Перед его стартом этапа Стороны должны проводить планирование этапа и формировать критерии готовности и тестирования этапа. В планировании каждого этапа участвует соответствующая рабочая группа экспертов из предметных специалистов Заказчика В планировании участвуют: - от имени Исполнителя: все члены команды или ключевые лица, которые полностью уполномочены действовать от имени членов, которых они представляют; - от имени Заказчика: Руководитель проекта и сформированная рабочая группа экспертов для каждого этапа. Команда Исполнителя формирует Список требований из Историй, которые включают необходимый и желаемый функционал для реализации, полученный в результате интервьюирования экспертов; 8

9 Руководитель проекта для каждого этапа формирует приоритеты для Историй из Списка требований, которые включают необходимый и желаемый функционал для реализации; Наиболее важные Истории реализуются в первую очередь; Истории с высоким приоритетом должны содержать больше деталей, чем менее приоритетные. Поэтому Команда Исполнителя проводит детализацию приоритетных Историй совместно с членами рабочей группы и формирует критерии готовности Историй; Команда Исполнителя проводит оценку количества Баллов для каждой приоритезированной Истории, изложенной в Списке требований проекта; Планирование итерации перед каждой итерацией команда Исполнителя формирует план работ (какие Истории будут сделаны за этот спринт) на данную итерацию в соответствии с важностью из Списка требований на данный этап и цель итерации. Руководитель проекта со стороны Заказчика согласовывает план реализуемых Историй за итерацию и цель итерации. Общее количество Баллов для реализуемых Истории не должно превышать общее количество Баллов для всего проекта, указанное выше в разделе: «Расчетная стоимость и относительная оценка». Список требований по проекту: Содержит начальный список Историй вместе с начальным значением приоритета Истории; и начальным значением Баллов для каждой из этих Историй. Список требований никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные Истории. Список требований постоянно обновляется по ходу реализации проекта и уточнению требований. Заказчик должен назначить приоритет для Историй, которые формируют План этапа Команда проекта проводит постоянный анализ требований с целью проработки и уточнения требований для последующих итераций и этапов. Команда проводит оценку только проанализированных требований и готовых к реализации Историй. 9

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

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

12 Роль Ф.И.О. Функции и ответственность Общее руководство проектом составление плана этапов, согласование плана Итераций и целей итераций, предоставление ресурсов, контроль за реализацией согласованного объема работ, контроль выполнения проекта в рамках бюджета и сроков, прямая ответственность за достижение результатов проекта. Основные функции: Определяет видение проекта; Утверждает план этапов проекта; Отвечает за формирование Списка требований; Отвечает за приоритезацию реализуемых требований; Контроль, обоснование и документирование любых изменений требований Заказчика к результатам проекта; «Единый голос» со стороны Заказчика по Управлению изменениями в Списке требований; Руководител ь проекта со стороны Заказчика Управление графиком встреч специалистов Исполнителя со специалистами Заказчика; Доступность для команды проекта на уровне 100%; Ответственность за предоставление запрошенной специалистами Исполнителя у специалистов Заказчика информации (документы, копии баз данных, удаленный доступ к информационным ресурсам и т.д.); Тестирование функций Системы; Ведение пользователей Системы; Подведение итогов по отдельным этапам проекта и по проекту в целом; Принятие результатов итераций и этапов проекта (визирование актов сдачи-приемки услуг со стороны Заказчика); Разрешение конфликтов в ходе выполнения проектов, в случае их возникновения; Мотивирование экспертов рабочих групп Заказчика; Информирование Инициатора и Куратора проекта о ходе выполнения работ. 12

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

14 Роль Ф.И.О. Функции и ответственность Руководител ь проекта Общее руководство проектом составление плана этапов, согласование плана Итераций и целей итераций, со стороны предоставление ресурсов, контроль за реализацией Исполнителя согласованного объема работ, прямая ответственность за достижение результатов проекта. Основные функции: Утверждает план этапов проекта; Отвечает за формирование Списка требований; Контроль, обоснование и документирование любых изменений требований Заказчика к результатам проекта; «Единый голос» со стороны Исполнителя по Управлению изменениями в Списке требований; Управление графиком встреч специалистов Исполнителя со специалистами Заказчика; Доступность для команды проекта на уровне 100% (гарантированная доступность руководителя проекта критерий успеха проекта); Подведение итогов по отдельным этапам проекта и по проекту в целом; Принятие результатов итераций и этапов проекта (визирование актов сдачи-приемки услуг со стороны Заказчика); Разрешение конфликтов в ходе выполнения проектов, в случае их возникновения; Мотивирование бизнес-аналитиков рабочих групп Исполнителя; Менеджер проекта Москалев М.В. Информирование Инициатора и Куратора проекта о ходе выполнения работ. Обеспечивает коммуникации между Заказчиком и Исполнителем; Контроль и администрирование договорных отношений (формирование актов по работам, счетов и контроль оплаты). 14

15 Роль Ф.И.О. Функции и ответственность Бизнесаналитики со стороны Исполнителя Эксперты по системе. Основные функции: Участие в обследовании бизнес-процессов; Настройка системы; Тестирование функционала; Обучение пользователей, подготовка инструкций. Таблица 6. Эксперты рабочих групп Рабочая группа, эксперт Рабочая группа этапа Рабочая группа этапа 15

16 Рабочая группа, эксперт Рабочая группа этапа

17 Управление проектом Коммуникации между участниками проекта. Коммуникации между участниками проекта будут осуществляться: на регулярных встречах рабочих групп для формирования и анализа требований и планированию этапов; на еженедельных встречах по планированию итераций; на еженедельных встречах по демонстрации результатов итераций (Демонстрация). На еженедельных встречах Исполнителем предоставляется отчетность по выполненным Историям. на еженедельных встречах по выявлению проблем и отклонений по проекту (формируется протокол по проблемам и отклонениям). В конце каждого месяца Руководитель проекта со стороны исполнителя представляет Отчет о работе за месяц и согласовывает с Руководителем проекта со стороны Заказчика График реализации проекта. дополнительные каналы для обмена информацией: электронная почта, телефон, бумажные носители информации, Skype. Внесение изменений в Устав проекта. Внесение изменений в Устав проекта может инициировать любой член проектной команды. Руководитель проекта рассматривает данное предложение в течение 3-х дней, затем принимает решение об отклонении либо вынесении предложения на согласование с руководителем проекта с другой стороны. Внесение изменений в проект осуществляется по согласованию сторон с оформлением рабочего протокола и заполнения листа изменений. В случае успешного согласования предложения между руководителями проекта обеих сторон предложение вносится в Устав проекта в согласованной редакции. После внесения изменений в Устав ему присваивается следующий по порядку номер версии и дата новой редакции, после чего изменения считаются вступившими в силу. Новая версия Устава подписывается заинтересованными сторонами проекта. 17

18 Изменения функциональных требований Внесение изменений в Список требований проекта осуществляется по согласованию сторон в любой момент во время этапа, без дополнительной оплаты, при следующих условиях: Заказчик не вносит изменения в Истории текущей Итерации, следуя согласованному плану Итерации; Новая История (Новые Истории) и/или вариации существующей Истории (Историй) могут быть введены, если существующая История (Истории) с эквивалентным числом Баллов удаляется или существующие Истории уменьшаются на эквивалентное число Баллов, так что общее число Баллов по Этапу остается постоянным в течение проекта. Процедура разрешения противоречий Все замечания фиксируются в письменном виде и высылаются руководителю проекта со стороны Исполнителя. Риски проекта В ходе выполнения проекта могут возникнуть следующие потенциальные проблемы, которые проектная команда планирует минимизировать либо исключить. Риски Метод минимизации/устранения 18

19 История изменений Версия Дата Автор(ы) Краткое описание изменений 19


Дата: 4 марта 2015 г. Номер страницы: 1 ООО «ЗАКАЗЧИК» 14 УСТАВ ПРОЕКТА Проект Замена летней резины на автомобиле (наименование проекта) Подготовлен: «20.03.2015» Дата: Вид документации: Проектная документация

Методика внедрения системы КУБ Москва 2016 г. Оглавление Введение... 5 Цели документа... 5 Задачи документа... 5 Глоссарий... 6 Термины и определения... 6 Роли в документе... 7 Цели и задачи проекта внедрения...

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ П О С Т А Н О В Л Е Н И Е от 15 октября 2016 г. 1050 МОСКВА Об организации проектной деятельности в Правительстве Российской Федерации В соответствии с пунктом 5 Указа

Открытое акционерное общество «Татнефть» имени В.Д. Шашина Во исполнении п. 4 протокола еженедельной планерки генерального директора от 08.12.2014г. 42/56-ПтПл Инструкция по управлению проектами Альметьевск

Андрей Петров «Богданов и партнеры» Корпоративный стандарт системы управления Создание КСУП НАЗНАЧЕНИЕ КСУП КСУП - свод информации о процессах, процедурах, методах и инструментах управления предприятия,

Эффективное взаимодействие с Заказчиком в проекте внедрения комплексной системы управления. Ирина Абрамова, старший менеджер, МАГ КОНСАЛТИНГ План презентации О проекте (цели, задачи,) Команды проекта

ПОРЯДОК выполнения процедур технического сопровождения, планирования и учета исполнения задач по развитию Программы для ЭВМ «Госзакупки» (АИС «Госзакупки») Применяемые понятия и определения: Плановая доработка:

ДЕПАРТАМЕНТ ПРОЕКТНОГО УПРАВЛЕНИЯ ХАНТЫ-МАНСИЙСКОГО АВТОНОМНОГО ОКРУГА - ЮГРЫ ПРИКАЗ О порядке инициации проектов г. Ханты-Мансийск 20 г. -нп В соответствии с пунктами 5.2, 5.4 Положения о системе управления

Утверждены Проектным офисом Правительства Российской Федерации 7 ноября 2016 г. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ по реализации первоочередных мероприятий в части организации проектной деятельности в федеральных

ОТКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО «РОССИЙСКИЙ СЕЛЬСКОХОЗЯЙСТВЕННЫЙ БАНК» (ОАО «РОССЕЛЬХОЗБАНК») В редакции решений Наблюдательного совета ОАО «Россельхозбанк» (протокол от 10.02.2012 4, протокол от 25.10.2012

1 РЕЗЮМЕ ПРАКТИКИ 1.1 Область специализации Информационные системы в управлении проектами в государственном секторе. Отрасли: Строительство, Транспорт, Электроэнергетика, Промышленность, Потребительский

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И ГОСТ Р 54871 2011 Проектный менеджмент ТРЕБОВАНИЯ К УПРАВЛЕНИЮ

Подробнее об услуге «Коробочное внедрение ИСУП» на базе MS Project Server 2007 Общая архитектура решения Ядром ИСУП, реализующим основную функциональность по управлению проектами, служат следующие модули:

Планирование Исполнение Контроль и анализ Принятие решения Управление проектами Информационные технологии ТЕХНОЛОГИЯ КОРПОРАТИВНОГО ВНЕДРЕНИЯ: РОЛИ, ФАЗЫ ЖИЗНЕННОГО ЦИКЛА, РИСКИ И ПЕРИОДИЧЕСКИЕ МЕРОПРИЯТИЯ

МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ (МИНКОМСВЯЗЬ РОССИИ) ПРИКАЗ Москва Об утверждении методических рекомендаций по организации системы проектного управления мероприятиями по

Дата текущей редакции: Стр. 1 из 14 УТВЕРЖДАЮ Генеральный директор 200_ г. Москва 200_ г. Дата текущей редакции: Стр. 2 из 14 Лист согласования Должность Подпись Дата ФИО Согласовано: Разработчики: Дата

Устав проекта Название проекта Информация о документе Дата документа Версия документа Статус документа Ответственный История изменений Дата Автор Примечание Содержание Содержание...

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ Н А Ц И О Н А Л Ь Н Ы Й С Т А Н Д А Р Т Р О С С И Й С К О Й Ф Е Д Е Р А Ц И И ГОСТ Р 54869 2011 Проектный менеджмент ТРЕБОВАНИЯ К УПРАВЛЕНИЮ

Опыт внедрения SAP GRC Process Control в ОАО «МегаФон» и тиражирование в ОАО «МегаФон Ритейл» Илья Губарев Руководитель по развитию корпоративных систем ОАО «МегаФон» МегаФон сегодня лидер в области передачи

О Порядке разработки и реализации муниципальных программ городского округа Новокуйбышевск Самарской области В целях обеспечения эффективной организации процесса разработки и реализации муниципальных программ

Применение Business Studio в проектах автоматизации Виктор Волонтей Управляющий партнер, руководитель компании «Правила бизнеса» (Беларусь, Минск) [email protected] [email protected] www.prabiz.by План мастер-класса

Номер страницы: 1 14 УСТАВ ПРОЕКТА ГАЗИФИКАЦИЯ Проект Газификация загородной квартиры (наименование проекта) Подготовлен: «Машутин В.С.» Дата: 22 марта 2015 г. Газификация квартиры Вид документации: Проектная

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ» УТВЕРЖДАЮ Ректор

ПМ ФОРСАЙТ Расширенное календарное планирование ГК «Проектная ПРАКТИКА» www.pmforesight.ru Программно-методический комплекс ФОРСАЙТ КСУП Корпоративная система управления проектами, включающая информационную

Приложение к Решению Комиссии Таможенного союза от 15 июля 2011 г. 715 Проект ПОЛОЖЕНИЕ о порядке взаимодействия Сторон при разработке проектной документации, сдаче-приемке и модернизации программно-аппаратных

З Приложение 1 к Регламенту «Порядок планирования» Форма УП-8План 5 О выполнении контрольной точки 6 Отчет о выполнении блока работ 7 Инициативная заявка на внесение изменений 8 Мониторинг

Содержание Предисловие 13 Благодарности 14 Введение 15 Часть I. Приступаем к работе 19 Глава 1. Общий обзор 21 Что такое пользовательская история 22 Где описывать детали 23 На скольких страницах я должен

1 Основы управления ИТ проектами. Лекция 1. Термин "ИТ-проект" обычно используется для обозначения деятельности, связанной с использованием или созданием некоторой информационной технологии. Это приводит

1 РЕЗЮМЕ ПРАКТИКИ 1.1 Область специализации Информационные системы в управлении проектной деятельностью в государственном секторе. Отрасли: Строительство, Транспорт, Электроэнергетика, Промышленность,

СТО 003-2016 Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования ИРКУТСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТЕХНИЧЕСКИЙ

Приложение 1 Требования к ИСУП «Аэроэкспресс» Состав требований: 1. Требования к автоматизации основных сценариев управления проектом 1 2. Требования к автоматизации основных сценариев управления Портфелем

Администрация Ненецкого автономного округа ПОСТАНОВЛЕНИЕ от 12 мая 2015 г. 145-п г. Нарьян-Мар О региональной информационной системе в сфере закупок товаров, работ, услуг для обеспечения нужд Ненецкого

Проектами с применением MS Project в решениях ГК «Проектная ПРАКТИКА» ГК «Проектная ПРАКТИКА» О чем будем говорить? Комплексная задача внедрения системы управления проектами Решения и практики по автоматизации

«УТВЕРЖДАЮ» «УТВЕРЖДАЮ» Старший вице-президент Флорентьева М.В 20 г. 20 г. БИЗНЕС-ТРЕБОВАНИЯ (BRD) НА РАСЧЕТ ПОКАЗАТЕЛЕЙ ПРЕДМЕТНОЙ ОБЛАСТИ «NNN» ДЛЯ ЕДИНОГО КОРПОРАТИВНОГО ХРАНИЛИЩА ДАННЫХ (ЕКХД) ПАО

ПОЛОЖЕНИЕ О КОМИССИИ ПО ОЦЕНКЕ ЭФФЕКТИВНОСТИ ДЕЯТЕЛЬНОСТИ РАБОТНИКОВ ФГБОУ ВО «НИЖНЕВАРТОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» Принято решением Учёного совета от 27 апреля 2015 г., протокол 14 Нижневартовск

Проектный офис Аутсорсинг. Запуск. Аудит. 2014 СОДЕРЖАНИЕ 1. Клиент: кому нужна помощь в развертывании проектых офисов и аутсорсинге специалистов 2. История: где это применялось 3. Продукт: что внутри

Бизнес-требования к проекту построения службы Data Helpdesk стр. 1 из 14 Содержание 1. Цели и задачи проекта... 3 1.1 Описание предпосылок и целей проекта... 3 1.2 Связь целей проекта с ИТ-стратегией Компании...

МУНИЦИПАЛЬНОЕ ОБРАЗОВАНИЕ ГОРОДСКОЙ ОКРУГ ГОРОД СУРГУТ ДУМА ГОРОДА СУРГУТА РЕШЕНИЕ Принято на заседании Думы 23 марта 2017 года 77-VI ДГ Об утверждении Порядка организации и проведения публичных слушаний

Техническое задание по автоматизации проектной деятельности Структура документа 1. Термины и определения. 2. Документы, использованные при создании технического задания 3. Общие сведения 4. Функциональные

СЭД 3 в минимальной поставке подразумевает поставку 50 х лицензий и 1 лицензии на систему потокового сканирования. Указанные цены могут быть изменены в 2016 году в зависимости от складывающейся экономической

Ппиложение 2 Технические решения на выполнение работ по внедрению Информационной системы управления проектами для нужд ООО «Аэроэкспресс» 1. Технологический подход 1.1. Программное обеспечение ИСУП. 1.2.

Заключительные этапы осуществления реформы электронных закупок в Армении www.ppi-ebrd-uncitral.com Запуск системы электронных закупок (eprocurement) ARMEPS армянская система электронных закупок www.armeps.am

Развернуть закупочное решение SAP за несколько недель - невероятно, но это факт! Дмитрий Иванов, руководитель направления ARIBA НОРБИТ И SAP НАДЕЖНЫЕ ПАРТНЕРЫ В РОССИИ И СНГ Компания НОРБИТ официальный

Гибкий подход к разработке OSS для крупного заказчика Уживутся ли Agile и крупный традиционный телекоммуникационный бизнес Александр Атцик, руководитель отдела развития Как мы предлагаем заказчику наше

ТВЕРСКАЯ ОБЛАСТЬ Правильная фокусировка проекта информатизации здравоохранения Тверской области Алексей Важнов Начальник Главного управления информационных технологий и связи Тверской области Выбор концепции

Управление человеческими ресурсами проекта Эффективное использование трудовых ресурсов одна из ключевых задач для компаний, которые занимаются проектированием, разработкой ПО, оказанием профессиональных

УТВЕРЖДАЮ Директор ГОБУ СПО «ЛОККиИ» 2014г. Н. А. Вартанян Комитет по культуре Ленинградской области Государственное образовательное бюджетное учреждение среднего профессионального учреждения «Ленинградский

Ключевые требования к информационной системе управления бизнесом для проектной компании Данный документ определяет состав ключевых бизнес-процессов для проектной компании с целью формирования требований

Инновация в образовании нововведение, влияющее на образование как социокультурную ценность, область деятельности, процесс и результат; инновационная деятельность это деятельность, ориентированная на качественное

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

УТВЕРЖДЕНО решением Совета директоров акционерного общества «Национальная компания «Қазақстан темір жолы» от «12» декабря 2011 г. протокол 7 Положение «О Корпоративном секретаре акционерного общества «Национальная

Обеспечение защиты информации на стадиях жизненного цикла при разработке информационных систем. Горбачев Евгений Васильевич Заместитель начальника управления ИБ начальник отдела защиты ИС апрель 2015 г.

Система организационно-распорядительного документооборота предприятия Описание функциональности Санкт-Петербург 2013 Содержание Общее описание «ОРД для SharePoint»... 3 ОРД... 4 Входящий документ... 4

СТРАТЕГИЯ. МЕТОДОЛОГИЯ И ПРОЦЕСС ПРОЕКТНЫЙ ОФИС КАК ЦЕНТР УПРАВЛЕНИЯ КОММУНИКАЦИЯМИ В статье рассматривается новая организационная структура проектного офиса как центра управления коммуникациями инвестиционного.

ПОРЯДОК ВНЕДРЕНИЯ ПРОЕКТНОГО УПРАВЛЕНИЯ В ОРГАНАХ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ ДОРОЖНАЯ КАРТА СТАРТ И ОРГАНИЗАЦИЯ РАБОТ Методические рекомендации по внедрению проектного управления в органах исполнительной власти

Постановление Правительства РФ от 02.08.2010 N 588 "Об утверждении Порядка разработки, реализации и оценки эффективности государственных программ Российской Федерации" ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

Дата текущей редакции: Стр. 1 из 8 УТВЕРЖДАЮ Генеральный директор Компании 200_ г. Москва 200_ г. Дата текущей редакции: Стр. 2 из 8 Лист согласования Должность Подпись Дата ФИО Согласовано: Разработчики:

Новые порядки в порядочном банке или история внедрения одной КСУП Докладчик: Елена Копылова Начальник Офиса управления проектами ОАО «АИКБ «Татфондбанк», PMP Декабрь, 2014 г. слайд 1 Татфондбанк Татфондбанк

УЧРЕЖДЕНИЕ ВЫСШЕГО О ОБРАЗОВАНИЯ Лист 1 из 10 УТВЕРЖДАЮ Декан художественнотехнологического факультета Васильев А.А. «16» ноября 2015 г. ОЦЕНОЧНЫЕ СРЕДСТВА ПО ДИСЦИПЛИНЕ Б2.В.ДВ.1.1 Организация проектной

Муниципальное предприятие «Ханты-Мансийскгаз» Муниципального образования город Ханты-Мансийск Директор А.В. Лоцманов 2011г. ПОЛОЖЕНИЕ о Единой комиссии по размещению заказов г. Ханты-Мансийск 2011 СОДЕРЖАНИЕ

Игорь АШМЕТКОВ, заместитель начальника Управления разработки информационных систем ОАО Банк ВТБ, кандидат физико-математических наук Сергей ПАЗИЗИН, руководитель группы защиты автоматизированных банковских

Утверждаю Заместитель Директора по информационным технологиям В.А. Коротков ИЗВЕЩЕНИЕ О ПРОВЕДЕНИИ ЗАПРОСА КОТИРОВОК К157-09-13/Структура баз данных (НИУ) г. Москва «19» сентября 2013 г. 1. Заказчик: федеральное

Октябрь Октябрь 2014 г Сценарий работы с модулем Заявка на открытие счета РКО (SugarCRM версия 6) HARDSOFT321.ORG Оглавление 1. Предварительные установки.... 3 2. Создание Заявки на открытие счета в системе....

Страница стр. 2 из 9 1 НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ Настоящее положение устанавливает порядок и правила организации и осуществления образовательной деятельности по дополнительным профессиональным программам

«УТВЕРЖДАЮ» Директор ГАОУ ЦО 548 «Царицыно» /Е.Л. Рачевский/ «18» сентября 2012 г. ВРЕМЕННОЕ ПОЛОЖЕНИЕ об электронном классном журнале ГАОУ ЦО 548 «Царицыно» 1. Общие положения 1.1. Электронный классный

Содержание 1. Термины и определения 2. Общие положения 3. Инициирование процедуры закупки 4. Подготовка, утверждение, размещение извещения и документации о закупке 5. Внесение изменений в извещение и документацию

Положение о взаимодействии комитета Ставропольского края по государственному заказу и заказчиков Ставропольского края ГУБЕРНАТОР СТАВРОПОЛЬСКОГО КРАЯ ПОСТАНОВЛЕНИЕ от 8 июня 2006 г. N 342 О НЕКОТОРЫХ МЕРАХ