Идеи и советы по ведению бизнеса, бизнес-идеи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка устава проекта

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

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

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

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

· ТЭО ;

· контракт;

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

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

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

На этапе формирования устава должно быть обязательно указано время начала и завершения проекта; при необходимости отмечаются ключевые вехи проекта , принципиальные для организации-заказчика. Вообще рекомендуется ограничить количество контрольных событий теми, которые абсолютно необходимы, т.е. обычно тремя-пятью. Иными словами, принимая во внимание цель устава и соответствующий уровень детализации, совершенно излишне разрабатывать длинный список событий - это только создаст дополнительные ограничения для выбора методологии реализации проекта. Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств Перечисление всех организационных факторов, характеризующих обстановку вокруг проекта и на рынке. Также необходимо указать благоприятные и неблагоприятные особенности среды, в которой проект будет выполняться (внутри и вне компании), и способность организации-исполнителя к его осуществлению, а организации-заказчика - к использованию его результатов. Далее (см. рис. 1.2) будет показан один из эффективных способов выполнения комплексного анализа окружения и участников проекта. При использовании этого подхода сначала определяется достаточно большое число факторов,действующих в окружении проекта ; они заносятся в соответствующий сектор. Затем выделяются наиболее критичные из них (прямоугольники - участники, овалы - факторы окружения) Набор условий, которые должны быть выполнены наряду с созданием продукта проекта, для достижения результата проекта. Допущения обуславливают риски проекта; во время проекта происходит их мониторинг. Пример допущений: · o компетенции команды проекта достаточно для выполнения предпроектного обследования; · o организацией-заказчиком будет выделен персонал для выполнения работ по поддержке проекта . Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организации-исполнителе Ограничение указывает на условие, которое нельзя нарушать в процессе создания продукта проекта, или условие, которому ни при каких обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору вариантов для выполнения любых проектных работ . Пример ограничений проекта: · увеличение стоимости проекта не более чем на 10%; · не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% в проекте . Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организации-исполнителе и о проекте в целом Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта . Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2 . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: · утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения; · назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; · формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; · вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; · принимать решения о внесении изменений в базовую линию проекта . Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта . Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса - словосочетание, не несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе? Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта 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: http://applied-research.ru/ru/article/view?id=10856 (дата обращения: 02.10.2017). Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

Устав проекта – документ, с которого начинается планирование проекта.

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

Устав проекта должен содержать следующую информацию:

Название проекта;

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

Цели Заказчика проекта Цели Заказчика определяют, что получит компания в результате выполненного проекта. Бизнес – цели компании обязательно учитывают стратегию развития компании, включая стратегию развития информационных технологий, на которую ориентирован проект. Например, увеличение капитализации Холдинга и привлечение инвесторов.

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

Функциональные организации и их участие(«участники» (stakeholders, англ)) Проекты обычно являются частью организации. Даже в том случае, когда проект является внешним для организации, проект все равно будет испытывать влияние со стороны организации, которая его инициировала.

Рис. 2. Принципиальная схема участников проекта.

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

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

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

Ключевые участники любого проекта: руководитель проекта, заказчик/пользователь, исполняющая организация,члены команды проекта,спонсор, источники влияния. В таблице 1 представлен пример возможных участников проекта внедрения ИС:

Таблица 1

Внешние участники проекта внедрения

Внешние участники проекта внедрения

Предприятия

Директора предприятий

Отдел по работе с персоналом

Ключевые функциональные специалисты

Пользователи

Информационные ресурсы

Информационное агентства

Тематические порталы

Управленческие журналы

Сообщества

Профессиональные сообщества

Профессиональные организации

Мероприятия

Выставки

Семинары

Конференции

Консалтинг

Бизнес-консультанты

Поставщики решений

Специалисты по внедрению

Интеграторы

Отношения между участниками проекта Участники проекта имеют различные уровни ответственности и полномочий в проекте. В таблице 2 представлены функциональные обязанности участников проекта. Менеджер проекта должен обеспечивать постоянный контакт команды проекта с ее участниками.

Таблица 2

Функциональные обязанности участников проекта

Функции участников проекта

Участники проекта

Разработка концепции проекта

Анализ и оценка жизнеспособности проекта

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

Разработка технологических процессов

Базовое проектирование (техпроект)

Проведение торгов, заключение контрактов

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

Закупка, поставки

Освоение и выпуск продукции

Условные обозначения :З - заказчик;РП -руководитель проекта;П - проектировщик;ГП – генеральный подрядчик;СП – субподрядчик;Б – банки;ОВ – органы власти;ПС – поставщик;В – владелец земли;Л – лицензоры;И - инженер;ИП – изготовители продукции;ПП – потребители продукции;* - должен осуществлять; Х - может осуществлять;

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

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

Сроки выполнения проекта включают даты начала и окончания проекта или продолжительность проекта

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

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

Примеры ограничений.

    10% членов команды проекта должны иметь сертификат PMI.

    Увеличение стоимости проекта не более чем на 10%

Примеры допущений.

Планируемую стоимость проекта. Первоначально, стоимость проекта определяется только на порядковом уровне. Ошибка в оценке стоимости колеблется (-20%)- (+100%) Стоимость проекта определяется контрактом между Заказчиком с Исполнителем. Исходя из стоимости проекта, в дальнейшем составляется бюджет расходов проекта с указанием статей расходов на внедрение ИС в разрезе месяца, квартала, полугодия, года.

Границы проекта. Определяются организационные, функциональные и географические границы проекта

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

Функциональные границы. Указываются бизнес - направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяется модули ERP-систем.

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

Команда проекта. На этапе разработке Устава проекта определяются контакты и должностные обязанности Спонсора и руководителя Проекта

Устав официально закрепляет назначение руководителя проекта , сдержит имена спонсора и руководителя проекта и определяет их полномочия.

А.Ю. Сооляттэ

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

Приложение

ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ

Пример 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. Работы Этапа I5.1.2. Поставляемые позиции Этапа I5.1.3. Работы Этапа II5.1.4. Поставляемые позиции Этапа II5.1.5.Работы этапа III5.1.6. Поставляемые позиции Этапа III5.1.7. Работы Этапа IV5.1.8. Поставляемые позиции Этапа IV5.1.9. Работы Этапа V5.1.10. Поставляемые позиции Этапа V6. Графики хода процессов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. ЛИСТ СОГЛАСОВАНИЙ ПРИЛОЖЕНИЯ