Основные укрупненные цели в уставе проекта. Примеры уставов проектов компаний. Как заполняются уставы проектов по услугам

Что нужно сделать до старта проекта. Часть 4

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

Фото с сайта d-express.su

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

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

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

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

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

Фото с сайта loveopium.ru

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

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

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

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

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

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

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

Фото с сайта ria.ru

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

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

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

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

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

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

Фото с сайта shkolazhizni.ru

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

Ведущий блога по управлению проектами.

Источник: https://probusiness.io/master_class/655-chto-nuzhno-sdelat-do-starta-proekta-chast-4.html

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

• 1 Место устава в процессах инициации
• 2 Состав и структура устава

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

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

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

Место устава в процессах инициации

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

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

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

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

Можно спросить в этой ситуации: «Позвольте, но в бизнес-плане все это описано?!». Действительно, бизнес-план подробно прорабатывает всю логику, инфраструктуру и экономику задачи, ее перспективы и финансовое обоснование. Но менеджер в большинстве случаев не может отвечать за все результаты, сформированные в бизнес-плане.

Его задача имеет более узкий контекст.

Основные выходы процесса инициации проекта

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

1. Ответственность менеджера ограничивается созданием нового продукта.
2. PM обеспечивает создание продукта и его производство.
3. Менеджер отвечает не только за создание и производство новой продукции, но и за его продажу в течение заданного периода времени.

Выписка из модели процессов инициации проекта

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

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

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

Состав и структура устава

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

• функцию постановки задачи;
• функцию согласования;
• авторизационную функцию;
• функцию повышения дисциплины;
• консолидационную функцию;
• интеграционную функцию.

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

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

1. Обоснование выполнения уникальной задачи развития.
2. Цели, задачи и результаты.
3. Имя и фамилию PM, границы его ответственности и полномочия.
4. Определение и структуру продукта.
5. Интересы и ожидания участников.
6. Критерии успеха.
7. Принципы организации и управления проектом.

Типовая структура устава проекта

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

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

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

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

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

Все это вносится в текст устава. Ниже размещен пример формы устава.

Форма приложения к уставу проекта

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

Документ начинает работать, используя свой потенциал полностью.

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

Источник: http://projectimo.ru/planirovanie-proekta/ustav-proekta.html

Чудо-бумажка, или зачем нужен устав проекта и как его написать

#документирование #инициация проекта #пример с ремонтом

Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.

Зачем нужен устав проекта

Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:

1. Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).
2. Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.
3. Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).

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

Важно! Начинать работу по проекту без подписанного устава – это самая плохая услуга, которую можно оказать самому себе как руководителю проекта.

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

Более того, подписание устава у заинтересованных сторон – это отличный индикатор того, действительно ли они заинтересованные или просто делают вид.

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

Как написать устав проекта

устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:

1. Начальные условия (Project Background) – что привело к инициации проекта, входные условия, «боль» Заказчика.
2. Цели и ожидания проекта (Project Objectives / Expectations) – чего мы хотим достичь на выходе. Это что-то должно быть измеримым (по SMART или как-то еще, неважно) и не допускать двойного толкования. Например, цель «сделать систему CRM, чтобы привлекать больше клиентов» – как-то не очень, правда? А вот «разработать и внедрить систему CRM для сотрудников отдела продаж Северо-Волжского филиала до 01.12.2015 для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года» – это уже немножко лучше.
3. и результаты (Scope and deliverables) – что именно мы включаем в состав проекта и какие конкретные результаты получим? Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку (а может, и саму организованную с нуля поддержку). В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включить подраздел со списком того, что в содержание проекта не входит в явном виде (чтобы все это согласовали и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили).
4. Ключевые требования и характеристики (Requirements and Characteristics) – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть «Срок обучения сотрудника системе не должен превышать 1 рабочего дня», «Поддержка системы не должна быть дороже 200 000 р. в год», «В системе одновременно должно работать не менее 300 человек» и подобное.
5. Бюджет и сроки (Cost and Timelines) – деньги, сроки и их взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию типа Бюджет–Сроки. Т.е. потратить больше денег прямо никак нельзя, уменьшать получаемые результаты сильно нежелательно (но можно, в самом крайнем случае), и если надо ради первых двух пунктов увеличить срок – это ок. Часто тут многие зависают, мол, «да нам все важно!», но в правильно мире вы идете к Спонсору и спрашиваете его, если спонсор адекватен – у него это понимание приоритетов точно есть, и он поделится им с вами.
6. Ключевые участники (Key Stakeholders) – основные заинтересованные лица, как минимум – Спонсор, Заказчик, те, кому придется делиться с вами ресурсами (в матричной структуре), ваш руководитель, держатель бюджета и т.д. Включать сюда всю компанию не стоит, просто подумайте и напишите: а) кто должен знать о проекте на этой стадии б) к чьему авторитету вам будет полезно апеллировать в ходе проекта
7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – про эти вещи мы еще поговорим подробнее, но в целом цель включения их в устав проекта – донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. Ну и чтобы потом никто не говорил «а нам не сказали».

Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория  – это хорошо, но не всегда понятно:

1. Начальные условия – живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. Я заказала дизайн-проект, мне нарисовали квартиру моей мечты, осталось только сделать.
2. Цель – сделать ремонт в квартире площадью 65 метров в строгом соответствии с дизайн-проектом не позже чем к такому-то числу и не больше чем за такие-то деньги.
3. и результаты (Scope and deliverables) – на выходе должны быть полностью замененные коммуникации (сантехника, электрика, отопление), новая входная дверь, новая сантехника, косметический ремонт (плитка в санузле, ламинат, обои и потолки во всех комнатах), заказанная и установленная кухня, полностью все освещение и вся мебель. Что не буду делать: отдирать стяжку пола (что ей стало-то за 15 лет), делать теплые полы и звукоизоляцию, и менять окна (они хорошие, только 2 года назад поставила).
4. Ключевые требования и характеристики – все должно быть в строгом соответствии с дизайн-проектом (см.пачку приложенных чертежей и смету), если что-то сделать нельзя или дороже больше чем на 10% – надо согласовывать на семейном совете. Разводку электрики и сантехники надо согласовать с местным ЖЭКом.
5. Бюджет и сроки (Cost and Timelines) – 2 млн. рублей на все, включая мебель и кухню (30% на черновую отделку и коммуникации, 20% на чистовую, включая сантехнику, 20% на кухню и 30% на мебель). Срок – максимум 4 месяца, т.к. мы всего на 4 месяца договорились к родителям переехать, в крайнем случае можно добавить еще 2 недели (поживем в гостинице). Приоритеты бюджет-качество-сроки (лучше в гостинице поживем, пока штукатурка будет сохнуть, но денег на тепловую пушку для сушки не выделим и клеить обои на мокрую штукатурку тоже не будем).
6. Ключевые участники (Key Stakeholders) – я, муж, родители, бригада, с которой я уже договорилась, соседи (надо уточнить, когда у них дети спят), ЖЭК (с ними надо проект согласовать).
7. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – допущения: соседи нескандальные, работать можно весь световой день, бригада адекватная и не будет бухать на объекте, курс доллара глобально не вырастет и стройматериалы сильно не подорожают; ограничения: нельзя работать после 22.00, не могу приезжать контролировать работу в будни (работаю), первая выплата бригаде возможна только в апреле (закончится депозит, где деньги на ремонт лежат); риски: возможно, ошибочно посчитана смета и денег на все не хватит, в дизайн-проекте ошибка, такую перепланировку узаконить нельзя, т.е. придется ремонт останавливать и все переделывать.

Ну и напоследок.

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

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

Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках.

И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия.

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

На кофе и новые материалы для читателей блога 🙂

Источник: https://upravlenie-proektami.ru/chudo-bumazhka-ili-zachem-nuzhen-ustav-proekta-i-kak-ego-napisat