Устав научно исследовательского проекта образец заполнения. Устав проекта: введение

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

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

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

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

Пример Устава проекта

Привожу пример устава проекта , который явился результатом бесплатного экспресс-обследования. Он отличается по форме от рекомендуемого 1С. Но, для понимания того, что именно должно быть указано в этом документе – вполне достаточно. Как и для того, чтобы понять, стоит ли начинать такой проект.

Устав проекта «Создание и внедрение системы 1С:Предприятие 8 в ХХХ»

1. Обоснование целесообразности проведения проекта

На предприятии используются несколько автоматизированных систем управления:

    Навигационная система движения автотранспорта (АСУТП) Система оперативного учета и обработки путевых листов в DOS; Система расчета заработной платы ХХХ Система учета ХХХ Система учета расчетов с поставщиками, бюджетом, учёта банковских и кассовых операций ХХХ Система сдачи налоговой отчетности «Контур-Экстерн»

В отдельных файлах Excel производится:

    Расчёт себестоимости по видам перевозок и статьям затрат; Учёт расчетов с заказчиками; Ведение операционного бюджета движения денежных средств ; Регистры бухгалтерского учёта ; Бухгалтерская отчётность.

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

    Выдача доверенностей; Журналы регистрации кассовых и банковских документов ; Журналы регистрации счетов-фактур; Заполнение налоговых деклараций и регистров налогового учета Ведение книги покупок и книги продаж

Составление различных планов осуществляется в смешанном режиме.

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

Данная ситуация приводит к несопоставимости данных в системах из-за влияния следующих факторов:

    Различные требования пользователей систем; Отличия в методологическом основании систем; Несовпадение нормативно-справочного наполнения систем; Ошибки при вводе данных и при составлении отчетности (человеческий фактор)

Это приводит к постоянной неопределенности при принятии управленческих решений менеджерами всех уровней.

Таким образом, назрела необходимость создания единого информационного пространства.

2. Цель(и) проекта

Стратегическая: повышение определенности при принятии управленческих решений через создание единого информационного пространства планирования и учёта финансово-хозяйственной деятельности .

Оперативные:

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

3. Ожидаемые результаты проекта

    Получение отчетности «по нажатию одной кнопки»:
      Оперативной По сравнению плана и факта Финансовой и налоговой отчетности Повышение квалификации пользователей;

4. Продукт проекта

Информационная система 1С, работающая в соответствии с поставленными задачами

5. Структура продукта проекта

    Методологическое обеспечение (методологии планирования и учёта; нормативно-справочная информация) Техническое обеспечение (сервер, сети, места пользователей) Программное обеспечение (система 1С, интегрированная с АСУТП и прочим внешним ПО) Обученный персонал (пользователи, администратор, служба поддержки) Документационное обеспечение ИС (техническая документация на изменения, инструкции пользователей)

6. Заинтересованные в развитии проекта стороны

    Генеральный директор Менеджеры различных уровней Начальник отдела АСУ Заказчики проекта (Главный бухгалтер, Главный экономист) Члены команды проекта со стороны предприятия Консультанты () Пользователи ИС

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

7. Ожидания заинтересованных сторон

    Генеральный директор: достижение целей проекта с минимальными затратами Менеджеры различных уровней: увеличение информированности при принятии управленческих решений Начальник отдела АСУ: снижение трудоемкости обслуживания ИС; повышение роли своей службы в системе управления; бонус за успешное выполнение проекта, опыт Заказчик проекта: снижение трудоемкости ведения учета; увеличение прозрачности учета; повышение профессионализма подчиненных. Члены команды проекта со стороны предприятия: бонус за успешное выполнение проекта, опыт, возможно, карьерный рост Консультанты: своевременная оплата работ, интересная работа, успешность проекта Пользователи ИС: повышение профессионализма, повышение рыночной стоимости

8. Риски проекта

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

Ограничения проекта

1. Время исполнения проекта

До 1 года – первый этап проекта (автоматизация бухгалтерского и оперативного учёта).До 1 года – постановка и автоматизация бюджетного управления и BSC

2. Затраты по проекту

Не более 3,5 млн. руб. на оплату услуг Консультантов в первый год и 4 млн. руб. – во второй год

3. Организационные

    Работы по проекту осуществляются в тесном контакте и под руководством Консультанта (компании – внедренца); Внедрение всех контуров учёта осуществляется единовременно, что требует серьёзной подготовительной работы и работы с персоналом (пользователей); Поддержка пользователей после окончания работ по проекту должна обеспечиваться силами сотрудников службы АСУ

4. Время команды проекта

До 06.10.20ХХ г.

    Проведение Консультантом анализа методологии и принципов организации учета на предприятии. Составление технического задания на проектирование ИС 1С. Выбор базовой конфигурации. Описание рисков проекта и мероприятий по их снижению. Разработка плана проекта.

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

До 25.11.20XX г.

4. Реализация проекта

До 22.01.20XX+1 г.

    Создание Консультантом информационной системы согласно технического проекта. Закупка программного обеспечения Модернизация аппаратно-технического обеспечения и сетевой инфраструктуры в соответствии с техническими рекомендациями Технического задания. Подготовка нормативно-справочной информации Подготовка данных по остаткам активов и пассивов

5. Опытно-промышленная эксплуатация

До 07.05.20XX+1 г.

    Обучение администрированию базы данных Ввод в ИС начальных остатков (по всем участкам учета) по состоянию на 01.01.20XX+1. Ввод первичных документов Пользователями с одновременным обучением и под контролем Консультантов по всем участкам учёта Работа Пользователей при дистанционной поддержке Консультантов Доработка ИС по результатам опытно-промышленной эксплуатации Разработка и оформление индивидуальных инструкций по наиболее сложным процессам учета и эксплуатации ИС

6. Завершение проекта

До 04.06.20XX+1 г.

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

Документы по проекту, требующие согласования и утверждения

Приказ о запуске проекта

Готовит Начальник АСУ, утверждает – Генеральный директор компании

План проекта

Техническое задание

Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант

Технический проект

Составляет Консультант, Согласовывает – Руководитель проекта, Утверждают – Генеральный директор и Консультант

Итоговый отчет по проекту

Готовит Начальник АСУ, утверждает Руководитель проекта

Ресурсы проекта

Отчетность по проекту

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Собрание

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3

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

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

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

Окончание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные документы проекта

Области знаний управления проектами

Грамотное и эффективное исполнение перечисленных процессов требует от менеджера проекта знаний в следующих областях:

1. Управление интеграцией проекта.

2. Управление содержанием

3. Управление сроками проекта.

4. Управление стоимостью проекта.

5. Управление качеством проекта.

6. Управление человеческими ресурсами проекта.

7. Управление взаимодействием.

8. Управление рисками проекта.

9. Управление контрактами проекта.

Карта связи процессов управления проектами и областей знаний согласно PMBOK приведена в таблице:

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

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

Разрабатывается четкое видение проекта,

Формулируются и обосновываются его цели,

Осуществляется базовое описание содержания проекта, планируемых результатов, длительности,

Составляется прогноз требуемых ресурсов.

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

1. Описание исходной ситуации. Кто заинтересован в проекте? Этот раздел - очень краткое описание существующей ситуации в области, в которой вы планируете произвести изменения и целевой аудитории (тех, кто заинтересован или будет вовлечен в процесс изменений).

2. Обоснование необходимости проекта. Зачем нужен проект? В этом разделе Вы должны предоставить существенные обоснования необходимости проекта. Не нужно вдаваться в детали вроде соотношения расходов и доходов.



3. Формулирование проблемы. Какую проблему решает проект? Существует опасность включить слишком много деталей в этот раздел. Сосредоточьтесь на основной проблеме, которую решает проект, детально опишите и проанализируйте ее, выявите причины ее возникновения.

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

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

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

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

Стандартный шаблон разделов Устава проекта следующий:

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

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

3. Миссия и цели проекта. Излагаются как стратегические цели, так и количественные цели и критерии с указанием трех ограничений. Например, «разработать и запустить в производство мобильный телефон, удовлетворяющий стандартам эргономики и безопасности ЕВРО-2, весом не более 70 грамм, за 8 месяцев при затратах, непревышающих 1 млн. долларов».

4. Деловые обстоятельства и бизнес задачи. Причины выполнения проекта. Ожидаемые выгоды. Субпродукты. Побочные продукты.

5. Финансовые показатели проекта. Предварительная оценка финансовых показателей.

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

7. Границы проекта. Конкретно указывается, что включается, а что исключается, т.е. выносится за рамки проекта.

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

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

10. Организация команды и взаимодействий.

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

12. Порядок сдачи-приемки работ заказчику. Что передается заказчику. Контрольный список вопросов. Что понимается под ожидаемыми результатами. Критерии приемки и проверки. В каких документах они прописаны.

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

На основе Устава проекта разрабатывается План проекта и другие документы.

Часто возникает проблема привлечения внешнего заказчика к подготовке Устава проекта и оплаты трудозатрат на его подготовку (кто делает и за чей счет). Практически работы по подготовке Устава проекта можно оформить двумя способами:

а) отдельной строкой в смете основного контракта на проект;

б) отдельным контрактом на подготовку Устава проекта.

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

Устав проекта разрабатывается его инициатором, который может быть:

Спонсором проекта;

Менеджером проекта или командой проекта;

Устав проекта утверждается:

Инициатором проекта;

Спонсором проекта;

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

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

Структура Устава проекта Международной компании, занимающейся разработкой и внедрением информационных систем.

С принятием Устава проекта завершается фаза инициирования проекта.

Описание содержания проекта

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

§ Российская ассоциация управления проектами «СОВНЕТ» - www.sovnet.ru

§ Project Management Institute - www.pmi.ru

В частности, российское отделение PMI выпустило перевод стандарта «Руководство к своду знаний по управлению проектами PMBOK GUIDE 2000», который можно приобрести по цене 520 руб.

Однако этот стандарт, как и все вообще стандарты носят обобщенный характер. А для организации управления проектом требуются конкретные документы.

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

Характеристики и рамки проекта,

Требования к продуктам и услугам, связанным с проектом,

Общее управление содержанием.

Менеджер проекта или команда проекта;

Представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта.

Спонсор проекта;

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

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

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

Приступая к работе над Содержанием проекта, вам необходимо учесть ряд взаимосвязанных действий, к которым относятся:

Описание запланированных изменений,

Разработка иерархической структуры работ (ИСР),

Разработка идеального графика работ,

Анализ ресурсов и другие.

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

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

  • Устав проекта (project charter);
  • Документ, определяющий содержание проекта (project scope statement (preliminary and detailed);
  • План управления проектом (project management plan).

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

Мы предлагаем рассматривать Положение о КСУП или корпоративный стандарт по управлению проектами (далее – корпоративный стандарт) как документ верхнего уровня в структуре внутренней нормативной документации, регламентирующей управление проектами в компании.

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

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

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

Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.

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

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

Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.

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

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

В корпоративный стандарт целесообразно включать следующие разделы:

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

УСТАВ ПРОЕКТА (PROJECT CHARTER)

Устав проекта (рroject charter) – один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI – PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.

Если обобщить существующие в проектной практике точки зрения, то получится, что под Уставом проекта разные специалисты, в т.ч. ориентирующиеся на PMBOK, понимают:

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

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

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

Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:

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

Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)

Кто разрабатывает документ: Устав проекта могут разрабатывать:

  • инициатор проекта;
  • спонсор проекта;

Кто утверждает документ: Устав проекта может утверждать:

  • инициатор проекта;
  • спонсор проекта;
  • представитель внешней стороны, связанной с проектом.

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

  • контракт;
  • Бизнес-потребности или требования к продукту, который будет создан в рамках проекта;
  • Цель проекта или основание для разработки проекта (justification);
  • Потребности и ожидания заинтересованных лиц (stakeholders);
  • Укрупненное расписание контрольных событий;
  • Влияние заинтересованных лиц на проект;
  • Распределение функций (functional organizations);
  • Предположения, связанные с внешним окружением и внутренней организационной средой;
  • Ограничения, связанные с внешним окружением и внутренней организационной средой;
  • Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI);
  • Укрупненный бюджет.

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

ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)

Ниже описано предназначение, содержание и порядок разработки и изменений Документа, определяющего содержание проекта, в соответствие с новой редакции PMBOK от 2004 года. В этом и в следующих разделах статьи использованы оригинальные английские термины, т.к. использование их русских аналогов, как заметил один из моих коллег, «очень часто ведет в дебри».

Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:

  • Характеристики и рамки проекта;
  • Требования к продуктам и услугам, связанным с проектом.

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

Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:

  • менеджер проекта или команда проекта;
  • представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта.

Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:

  • спонсор проекта;
  • представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

  • Устав проекта;
  • документ определения работ (Statement of work);
  • факторы внешнего окружения и организационной среды;
  • организационные активы (Organizational process assets).
  • Цели проекта и цели предметной области проекта;
  • Требования и характеристики продукта или услуги;
  • Рамки проекта;
  • Проектные решения (deliverables);
  • Критерии приемки продукта;
  • Проектные ограничения;
  • Проектные предположения;
  • Организация проекта на начальной стадии;
  • Идентификация рисков на начальной стадии;
  • Расписание контрольных событий;
  • Предварительный расчет стоимости (Order of magnitude cost estimate);
  • Требования к управлению конфигурацией проекта;
  • Согласованные требования (Approval requirements).

Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.

ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)

Ниже описаны предназначение, содержание и порядок разработки и изменений Плана управления проектом, в соответствие с новой редакции PMBOK от 2004 года.

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

Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.

Кто разрабатывает документ: менеджер проекта или команда проекта с участием других заинтересованных лиц.

Кто утверждает документ: План управления проектом может утверждать:

  • спонсор проекта;
  • представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

  • Устав проекта;
  • Project Scope Statement (preliminary);
  • Процессы управления проектом;
  • Прогнозы
  • Факторы внешнего окружения и организационной среды;
  • Организационные активы (Organizational process assets);
  • Информация о выполнении работ.
  • Процессы, выбранные командой управления проектом;
  • Уровень внедрения каждого выбранного процесса, определенный командой управления проектом;
  • Описание средств и техник, используемых для выполнения этих процессов;
  • Выбранный жизненный цикл проекта и связанные с ним фазы проекта;
  • Как выбранные процессы будут использованы для управления конкретным проектом. Включение зависимостей и взаимодействий между этими процессами и необходимых входов и выходов;
  • Как будет организовано выполнение работы для достижения целей проекта;
  • Как будут осуществляться мониторинг и контроль изменений;
  • Как будет осуществляться управление конфигурацией;
  • Как будет обеспечиваться интеграция исходных планов (baselines) проекта;
  • Потребности в информации и техники коммуникаций между заинтересованными лицами;
  • Ключевые управленческие обзоры по содержанию, масштабу, выбору сроков проекта, обращенные к открытым вопросам и предстоящим решениям по проекту.

План управления проектом может суммировать/объединять все отдельные планы проекта или некоторые из них:

  • План управления содержанием;
  • План управления расписанием;
  • План управления стоимостью;
  • План управления качеством;
  • План улучшений;
  • План управления персоналом;
  • План управления коммуникациями;
  • План управления рисками;
  • План управления поставками.

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

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

А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты – [email protected] .

Приложение

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

Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).

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

Данный документ – Устав проекта – уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).

СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация

Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)

СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 – ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 – СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 – ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 – ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 – ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 – ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 – РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 – ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.

Пример 3. УСТАВ ПРОЕКТА (Российская компания – системный интегратор)

СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ

Руководитель проекта назначается уставом проекта и формально приступает к выполнению своих обязанностей на следующий день после подписания устава проекта. Руководитель, или менеджер, проекта несет основную ответственность за общее планирование, направление и контроль проекта в течение всех фаз его жизненного цикла, ставя целью получение желаемого результата в рамках утвержденного бюджета и расписания. Основная задача руководителя проекта - объединение усилий всех лиц, участвующих в проекте. Для решения этой задачи менеджер проекта наделяется полномочиями по проекту, т.е. правом отдавать функциональным лидерам проекта распоряжения, необходимые для планирования, исполнения, мониторинга, оценивания и контроля работ, которые должны быть выполнены по данному проекту. Руководство проектом также включает в себя получение информации, необходимой для планирования, мониторинга, оценивания и контроля проекта . Роль спонсора проекта обычно берет на себя (не назначается!!!) менеджер высшего звена, который действует от лица руководства компании, финансирующей или исполняющей проект 2 . Ключевая задача спонсора заключается в обеспечении ресурсов проекта, в том числе административных, а также в обеспечении связи между проектом и руководством организации-заказчика. На проекте спонсор является лицом, принимающим те решения, которые находятся за пределами полномочий руководителя проекта, например: · утверждать бизнес-цели проекта, включая расписания и бюджет, и вносимые в них изменения; · назначать и утверждать менеджера проекта, а также утверждать соответствующую должностную инструкцию и порядок подчинения; · формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта; · вносить и утверждать основные изменения по проекту и решения, касающиеся выделения ресурсов; · принимать решения о внесении изменений в базовую линию проекта . Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта . Администратор (координатор) проекта - это специфическая функция на проекте, которая необходима для поддержки работ, связанных с администрированием и документированием функционирования проектной организации и обеспечением инфраструктуры проекта. Работа администратора имеет своей ключевой задачей поддержку руководителя проекта на операционном уровне с целью его высвобождения для интеллектуально-сложных задач. В обязанности координатора проекта может входить: администрирование проектных контрактов и договоров на протяжении всего ЖЦ, организация периодического сбора статуса выполнения проекта и т.п. сбор статуса - словосочетание, не несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе? Формировать всю команду и тем более сразу указывать имена всех ее членов не принято - функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на ресурсы, утвержденный спонсором проекта
  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то