Устав проекта: введение. Внедрение программного продукта. Устав проекта

С развитием информационных технологий и телекоммуникаций наша жизнь становится все более мобильной и информативной, новые технологии прочно входят в различные отрасли хозяйствования, сферы жизни и несут новые нормы в них. В связи с реформированием экономики РФ, с взятием курса на инновационное развитие экономики, всё чаще и чаще в повседневной работе в большинстве предприятий и организаций используют различные средства информационно вычислительной техники и соответственно программного обеспечения. Но необходимо заметить, что спонтанное, не спланированное развитие в любой деятельности малоэффективно. Поэтому очень важно знать и владеть таким программным обеспечением, как 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Искусство управления проектом заключается в том, чтобы неведомое сделать предсказуемым. И чем раньше выявятся подводные камни – тем больше шансов не нахлебаться воды.

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

Устав проекта определяет каркас проекта в 5 измерениях:

• ЦЕЛИ и ТРЕБОВАНИЯ
• ЗАДАЧИ
• РИСКИ
• УЧАСТНИКИ
• ПРАВИЛА

Также может добавляться еще шестое измерение – РЕСУРСЫ (бюджет и иные).

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

Чтобы определить каркас проекта в этих измерениях необходимо:

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

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

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

Успешной команде нужна разработка устава проекта — «прощупать» проект, пока корабль еще не укомплектован и не отошел от берега. И важен не сам документ, а те задачи, которые придется решить, чтобы наполнить его смыслом.

Рассмотрим подробнее эти задачи.

Для описания задач воспользуемся методологией функционального моделирования IDEF0.

Модель процесса разработки устава проекта

Цель моделирования: показать основные этапы, необходимые для начала проекта, их взаимосвязь и результаты, приводящие к формированию отчетного документа «Устав проекта», а также определить основные требования к процессу разработки устава проекта и требования к содержанию устава проекта.

Точка зрения: Руководитель проекта.

Контекст: Для того, чтобы показать место процесса по разработке устава проекта и самого устава проекта в жизненном цикле проекта, контекстная диаграмма А0 соответствует процессу выполнения проекта в целом и затем детализируется на отдельные этапы. Данная модель не противоречит PMBOK 4, но обладает большей детализацией с точки зрения процесса разработки устава проекта.

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

На диаграммах А0-А1 (рисунок 1 и 2) отражен контекст интересующего нас процесса.

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

Обычно работы по проекту начинаются с получения каких-то исходных данных, будь-то брошенная вскользь идея заказчика или формализованное ТЗ на 200 страниц. С этих исходных данных и предстоит начать «разматывать клубок» в ходе разработки устава проекта.

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

Если проект инициирован, то собранные в ходе разработки устава проекта высокоуровневые данные по всем 5(6) измерениям проекта должны быть детализированы на следующих этапах. Устав проекта является руководящим документом для последующих этапов, что и отражено на диаграмме А1 на рисунке 2.

Хотя на диаграмме А1 не отражена обратная связь между блоком А1.4 Анализировать проект и А1.1 Разработать устав проекта , нельзя забывать, что и устав проекта не является его «догмой» и может быть пересмотрен в любой момент для лучшего соответствия актуальным целям проекта и ситуации. Например, в ходе выполнения проекта выяснилось, что появляется несколько ключевых пользователей разрабатываемой системы, они безусловно должны быть включены в проект и его систему коммуникации, а их ожидания учтены и соотнесены с целями проекта.

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

Введенные на первых двух диаграммах потоки, определены в таблице ниже.

Таблица 1. Потоки данных для А0-А1

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

Таблица 2. Потоки данных для А1.1

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

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

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

Хорошая практика формулирования целей заложена в принципах SMART . Чтобы можно было добежать до цели, а не только согреться, необходимо указать критерии достижения целей проекта (блок A1.1.1.3) , т.е. показатели, которые возможно измерить, а также их значения. Это позволяет снять целых комплекс конфликтов и рисков неуспешного завершения проекта. Представьте, что вы руководитель проекта, вы выполнили проект в срок, уложились в бюджет, достигли сформулированной цели проекта — снизили затраты на изготовление продукции. А заказчик считает проект неуспешным, отказывается принимать результаты и соответственно делать выплаты. В чем же дело? Дело в том, что вы снизили затраты на 3% за 1 год, а заказчик считал, что они должны быть снижены на 10% за полгода, тогда проект для него считается успешным .

Эта сложная задача часто игнорируется, что приводит к неуспешным проектам и отражено в известной статистике ИТ- отрасли .

Таблица 3. Потоки данных для А1.1.1

Расширенный материал по формированию системы целей с иллюстрациями приведен в статье ?

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

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

Риски проекта сильно влияют на его план и ресурсы, т.к. в нем[плане] должны быть предусмотрены меры по их предотвращению или хотя бы по снижению негативных последствий.

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

Таблица 4. Потоки данных для А1.1.2

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

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

Таблица 5. Потоки данных для А1.1.3

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

Заключение

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

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

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

Мадорская Ю.М. Разработка устава проекта. Методическое пособие. //Практика проектирования систем.-2017.. - Загл. с экрана

Литература

1. Тимофеев А.Н. Почему падают ИТ-проекты? //Практика проектирования систем.-2017.. - Загл. с экрана
2. Duncan Haughey. Smart Goals //Project Smart.-2017. [электронный ресурс] — Режим доступа:https://www.projectsmart.co.uk/smart-goals.php, свободный. - Загл. с экрана