Транскрипт

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 О НЕКОТОРЫХ МЕРАХ

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

В трех предыдущих статьях серии «Что нужно сделать до старта проекта» я рассказал, что перед стартом необходимо:

• Сформулировать бизнес-проблемы, цели проекта и ожидаемые результаты .

Для старта проекта еще следует определить ключевые роли в нем (о том, что это за роли читайте ) и написать документ, в котором руководитель проекта и заказчик договариваются об общем видении начинания.

Документ, с которого проект стартует, называют Уставом проекта (или Паспортом проекта).

Устав проекта - это документ, с которого начинается проект и по которому происходит оценка его успешности.

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

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

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

В популярном подходе к управлению проектами - PMBOK - в состав «Устава проекта» входят следующие разделы:

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

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

Кто разрабатывает Устав проекта?

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

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

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

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

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

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

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

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

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

Для понимания структуры документа приведу пример Устава внедрения CRM-системы.

УСТАВ ПРОЕКТА
Автоматизация процессов CRM. Версия 1.0

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

Выводы

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

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

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

Максим Якубович

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами - более 10 лет.

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.

Опыт преподавания - 10 лет. Около 2200 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий

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

Разработка устава проекта – это процесс разработки устава проекта.

В стандарте PMBOK 5 – разработка устава проекта относится к области знаний .

Перечислим список тех пунктов, которые может включать в себя устав проекта:

• Обоснование проекта
• Измеримые цели проекта и критерии их успеха. Подробнее про критерии успеха можно прочитать в статье Постановка целей по модели SMART .
• Первичные требования. Часто эти требования называют высокоуровневыми.
• Ограничения и допущения.
• Описание проекта и его границы
• Упоминания об основных рисках проекта
• Бюджет проекта
• Информацию о .
• Информация о
• Информация о
• Информация о

В самом просто виде устав может выглядеть как-то так:

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

Менеджером проекта назначаю моего верного холопа Ивана. Обеспечивать его ресурсами и помогать будет граф Графович, а работы будут принимать я.

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

Бизнес-вопросы.

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

Технологические вопросы.

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

Структурные вопросы (эти вопросы учитывают возможные влияния законов и культуры компании на проект).

• Какие государственные стандарты могут повлиять на проект? Например, если ИТ-решение потребует сертификацию, то это необходимо учитывать, чтобы заложить возможные издержки на это в проект.
• Какова корпоративная культура и стратегия компании, в которой вы работаете? Как стандарты принятые в компании влияют на ваш проект? Например, вы запускаете сайт и ваша компания работает в этом направлении с одним давно проверенным вендором. Следовательно, вы должны учесть это при разработке устава проекта.
• Что сейчас происходит на рынке? Легко ли вам будет найти ресурсы для реализации проекта?

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

Вопросы прошлого опыта (эти вопросы помогут вам использовать прошлый опыт ваш и ваших коллег для ускорения работ по проекту)

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

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

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

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

Формирование бизнес-цели проекта

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

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

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

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

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

· стратегические и тактические цели организации-заказчика;

· формулировка требований организации-заказчика;

· ТЭО (технико-экономическое обоснование) ;

· контракт;

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

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

В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

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

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

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

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

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

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

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