Устав проекта это бизнес план проекта
Автор статьи:
Основатель Projectimo.ru
Свежие публикации автора:
Процесс инициации проекта преследует несколько целей. Высшее руководство компании должно принять необходимость выполнения проекта. Он подлежит идентификации и определению в качестве нового объекта управления. В ходе инициации также выполняется организационное обеспечение запуска его в реализацию. Данные цели достигаются по ходу соответствующих деловых процессов, выходами которых являются готовность к этапу планирования и ряд основополагающих документов. Одним из таких документов, разрабатываемых в процессе инициации, является устав проекта.
Место устава в процессах инициации
Для начала инициации важна идея, которая рождается в сознании инициатора, и суть своего замысла он намерен доложить руководству компании. Неоформленная идея аморфна, поэтому должен появиться исходный документ для принятия первоначального решения. Если работа предполагается небольшой, то замысел и ее эффекты оформляются в виде концепции, бизнес-кейса, презентации на несколько страниц и слайдов. Если замысел отличается масштабностью, то после рассмотрения исходных документов дается указание на разработку ТЭО и бизнес-плана. По факту их готовности руководство вновь возвращается к вопросу, и после успешной защиты принимается решение – проекту быть.
Дальше производится серия новых действий и принятие новых решений для того, чтобы запустить начало проектного мероприятия. Мероприятие в результате этих действий становится объектом управления. Иными словами, определяется менеджер проекта, и ему предлагается уникальная задача со всеми необходимыми параметрами. Можно спросить в этой ситуации: «Позвольте, но в бизнес-плане все это описано?!». Действительно, бизнес-план подробно прорабатывает всю логику, инфраструктуру и экономику задачи, ее перспективы и финансовое обоснование. Но менеджер в большинстве случаев не может отвечать за все результаты, сформированные в бизнес-плане. Его задача имеет более узкий контекст.
Основные выходы процесса инициации проекта
Если рассматривать пример создания нового рыночного продукта, предполагаемого к производству компанией, то уровень задачи PM может быть ограничен как минимум тремя вариантами ее контуров.
- Ответственность менеджера ограничивается созданием нового продукта.
- PM обеспечивает создание продукта и его производство.
- Менеджер отвечает не только за создание и производство новой продукции, но и за его продажу в течение заданного периода времени.
Выписка из модели процессов инициации проекта
Уровень задачи менеджера должен быть определен и зафиксирован в специальном документе, который именуется уставом. Устав проекта – документ, издаваемый руководством компании для целей постановки ответственному ресурсу в лице PM уникальной задачи, предполагающей установленную зону ответственности и полномочий. Ответственность менеджера предусматривает его право принять уникальную задачу к исполнению и обязанность выполнить, не ссылаясь на вновь возникшие ограничения (в идеальном случае). Полномочия PM позволяют ему привлекать и использовать ресурсы компании и внешние заинтересованные стороны для достижения результатов в намеченные сроки. Устав проекта занимает первоочередное место после начала работ над проектом и решения о его старте, что отражено на представленных выше схемах.
Состав и структура устава
Устав проекта обеспечивает непосредственную связь уникальной задачи со стратегическими целями компании. Играя роль документа, формально авторизующего задачу, устав включает в свой состав базовые требования и основные ожидания заинтересованных сторон. Этот документ выполняет несколько функций, среди них важно отметить:
- функцию постановки задачи;
- функцию согласования;
- авторизационную функцию;
- функцию повышения дисциплины;
- консолидационную функцию;
- интеграционную функцию.
Разработка устава проекта начинается после издания приказа о запуске. Распорядительная часть документа формально фиксирует дату старта проектной реализации, в ней вводится его полное и краткое название, назначаются куратор, руководитель (PM), ответственные лица за ключевые блоки. В приказе, как правило, отражается укрупненный план проекта в одной из первых его редакций. Структурная схема устава приводится далее. Он разрабатывается итерационно и может иметь несколько редакций, постепенно уточняющих основные положения, которые включают следующие аспекты.
- Обоснование выполнения уникальной задачи развития.
- Цели, задачи и результаты.
- Имя и фамилию PM, границы его ответственности и полномочия.
- Определение и структуру продукта.
- Интересы и ожидания участников.
- Критерии успеха.
- Принципы организации и управления проектом.
Типовая структура устава проекта
Выше представлен один из вариантов типовой структуры устава. Устав проекта – достаточно сложный в разработке и введении в действие документ, часто являющийся первым формальным документом проекта. Обычно работу с ним начинает куратор, включая в него укрупненно сформулированные цели, ожидаемые результаты и образ продукта проекта. Далее заготовка устава передается PM для завершения разработки первой редакции документа, которых может быть несколько.
Менеджер осуществляет сбор дополнительной информации, совместно с куратором организует предварительные совещания с основными участниками и будущими членами проектной группы. В результате данных мероприятий менеджер проясняет связь со стратегией, интересы и ожидания заинтересованных сторон. Становятся понятны потребности, опасения участников, формируется видение продукта, основных ограничений и критериев успеха. Все это вносится в текст устава. Ниже размещен пример формы устава.
Форма устава проекта
Форма приложения к уставу проекта
Вполне обычной практикой является переутверждение устава после одного, двух этапов реализации проекта, когда происходит окончательное прояснение, например, рыночного потенциала продукта, декомпозиции задачи и подзадач. Документ начинает работать, используя свой потенциал полностью. Играя роль письменно закрепленной задачи, договора между заказчиком и менеджером проекта, устав формирует ценностно сплачивающий команду контекст, реализуя который, PM и другим участникам значительно проще находить мотивацию на достижение успешного результата.
Источник
В управлении проектами устав проекта, определение проекта или статус проекта, это документ, содержащий сведения о сфере деятельности, целях и участниках проекта. Он предусматривает предварительное разграничение ролей и обязанностей, описывает цели проекта, определяет основные заинтересованные стороны и определяет полномочия менеджера проекта. Фактически этот документ служит описанием для будущего проекта, а техническое задание является его частью.
Устав проекта должен:
- Описывать суть проекта.
- Обеспечивать общее понимание проекта.
- Обозначать зоны ответственности между спонсором проекта, основными заинтересованными сторонами и проектной командой
Устав проекта обычно представляет собой небольшой документ, который ссылается на более подробные документы, например, требования к проекту.
По Initiative for Policy Dialogue (IPD) этот документ называется устав проекта. В системе управления взаимоотношениями с клиентами (CRM) он известен как определение проекта. И IPD, и CRM требуют чтобы этот документ был частью процесса управления проектами.
Устав проекта уточняет полномочия, назначенные руководителю проекта. Особенно это полезно в матричной среде управления.
Цель устава проекта заключается в том, чтобы документировать:
- Причины для реализации проекта
- Цели и ограничения проекта
- Указания относительно решения
- Указание основных заинтересованных сторон
- Объекты, входящие в область действия и вне сферы охвата
- Риски, выявленные на раннем этапе (план управления рисками должен быть частью общего плана управления проектами)
- Преимущества целевого проекта
- Высокоуровневое бюджетирование и определение ответственных за расходы
Три основных вида использования проекта:
- Чтобы санкционировать проект используя сопоставимый формат, например проекты могут быть ранжированы и разрешены окупаемостью инвестиций.
- Служит основным документом продаж для заинтересованных сторон, имеющих рейтинг проекта, имеет сводку на 1-2 страницы, чтобы распространять, представлять и сохранять удобство для предотвращения других проектов или операций, выполняемых в ресурсах проекта.
- Служит фокусом во всем проекте. Например как опорная стратегия, которая может использоваться в командных встречах и совещаниях по управлению изменениями для содействия менеджменту.
Для большого многоэтапного проекта устав может быть создан для каждого отдельного этапа. Например, может быть устав проекта во время этапов «Ниша» и «Поиск» проекта, за которым следуют устав планирования и устав исполнения на этапе сборки проекта.
Устав проекта создается инициативной группой в самом начале. Разработка устава и определение заинтересованных сторон – это два основных действия инициативной группы.
Вклады для разработки устава могут быть:
- Заявление о работе проекта
- Технико-экономическое обоснование
- Соглашения и договоренности
- Стандарты предприятия, отраслевые стандарты, правила и нормы
- Организационный процесс, структуру и шаблоны
Как правило, менеджер проекта возглавляет разработку устава на основании своей экспертизы и предыдущего опыта разработки устава. Менеджер проекта в процессе разработки устава должен работать с ключевыми заинтересованными сторонами (клиентами и бизнес-спонсорами), специалистами в организации, экспертами по предметным вопросам внутри и вне организации, другими подразделениями в организации и может также работать с отраслевыми группами или профессиональными организациями. Менеджер проекта для разработки устава может использовать вспомогательные действия, такие как мозговой штурм, устранение проблем, разрешение противоречий, встречи, управление ожиданиями и т.д.
Единожды составленный устав предоставит руководителю проекта полномочия для официального выполнения проекта и использования организационных средств и ресурсов для успешного осуществления проекта.
Ссылки[править | править код]
Источник
Устав проекта
Устав проекта (Project Charter) является официальной авторизацией проекта и разрабатывается Руководителем проекта с привлечением членов команды управления проектом со стороны Исполнителя. Устав проекта согласовывается с командой управления проектом со стороны Заказчика и утверждается Спонсорами проекта как со стороны Исполнителя, так и со стороны Заказчика.
Процесс разработки Устава проекта относится к группе процессов Инициация и осуществляется в фазе (на этапе) проекта внедрения ИС, которая имеет свое специфическое название в каждой методологии внедрения ИС, например, “Предварительное определение проекта”, “Определение проекта” – методология внедрения продуктов Microsoft, “Концепция” – методология внедрения ASUP.
Исходными документами для разработки Устава проекта внедрения ИС являются контракт и результаты предпроектного обследования, определяющие содержание работ по проекту. Результаты предпроектного обследования оформляются в виде отчета, включая описание бизнес-процессов верхнего уровня.
Устав проекта содержит следующую информацию:
1. Название проекта.
2. Бизнес-цели компании или причины возникновения проекта.
Формулировка причины фактически дает ответ на вопрос ” Зачем выполняется данный проект?”.
Бизнес-цели компании обязательно учитывают стратегию развития компании, включая стратегию развития информационных технологий, на которую ориентирован проект, – например, увеличение капитализации Холдинга и привлечение инвесторов.
3. Цели проекта.
Цели проекта определяют, что должно быть выполнено, и описывают конечный результат проекта. В Уставе проекта приводится цель проекта как результат, ожидаемый Заказчиком и полезный для него. Цель формулируется совместно Заказчиком и Исполнителем.
При формулировании цели руководитель проекта должен контролировать ее соответствие контракту, в рамках которого будут выполняться работы по проекту.
Формулировка целей должна соответствовать следующим критериям ( SMART- Specific, Measurable, Achievable, Relevant, Time-bound ):
- Конкретные (Specific) – позволяющие сформировать расписание проекта;
- Измеримые (Measurable) – позволяющие качественно (или количественно) оценить, что результат получен;
- Достижимые (Achievable) – принципиально реализуемые Исполнителем в рамках проекта, с учетом декларируемой помощи со стороны Заказчика;
- Приносящие результат (Relevant) – соответствуют ожидаемой Заказчиком пользе;
- Ограниченные во времени (Time-bound) – реализуемые в ожидаемые Заказчиком временные рамки проекта.
Результаты проекта должны соотноситься со спецификацией контракта, в рамках которого будут выполняться работы по проекту.
Примеры формулировок целей:
- Проектирование единых унифицированных бизнес-процессов в Головной компании и дочерних компаниях холдинга.
- Разработка единого унифицированного ERP-решения, которое предназначено для внедрения в Холдинге, состоящем из Головной компании и 10 дочерних компаний.
- Разработка инструментальных средств развертывания/тиражирования полученного решения во всех дочерних компаниях Холдинга.
4. Границы проекта.
Границы проекта определяют в целом то, что включается в проект. Необходимо явно указывать, что не включается в проект (таблица 4.2), чтобы исключить ситуацию, когда участник проекта ошибочно считает некоторый продукт, услугу или результат входящими в проект.
- Организационные границы
Определяется, какие подразделения (включая юридических лиц) должны участвовать в проекте – кто будет использовать и поддерживать ИС, от кого зависит выработка основных решений по требованиям к ИС. Организационные границы определяют максимальные границы обследования и область рождения требований к ИС.
- Функциональные границы
Указываются бизнес-направления, бизнес-процессы, которые будут покрываться ИС. Данным пунктом определяются модули ERP-систем.
- Географические границы
Указываются территориально удаленные объекты, подлежащие автоматизации.
| Раздел функциональности | Процессы, не подлежащие реализации |
|---|---|
| Организационный менеджмент | Формирование фонда заработной платы по специфичным методикам. Система оповещения по функциям Управления персоналом в целом. Ведение аттестации рабочих мест, вредных условий труда |
| Администрирование персонала | Ведение параллельных данных на английском языке |
| Учет рабочего времени | Фактический учет рабочего времени (будет использоваться негативный учет). Учет рабочего времени по заказам/объектам. Учет работы во вредных условиях |
| Расчет зарплаты | Сдельная система оплаты труда |
5. Содержание проекта (задачи проекта).
Содержание проекта отвечает на вопрос “Какую конкретную работу нужно выполнить для достижения поставленных целей?” или “Какие задачи необходимо решить для достижения поставленных целей?”. Содержание может быть получено от Заказчика в качестве составляющей тендерной документации.
Пример описания содержания (задач) проекта
Автоматизация бизнес-процессов:
- Управление основными средствами.
- Учет затрат.
- Управление персоналом.
Требования к бизнес-процессам должны включать:
- Требования законодательства РФ в области бухгалтерского, налогового и статистического учета и отчетности.
- Требования международных стандартов финансового учета и отчетности.
- Требования управленческого учета Головной компании Холдинга.
- Требования внутренней отчетности (внутреннего аудита).
- Требования ТК РФ, отраслевой отчетности, отчетности Головной компании Холдинга.
Источник
Юлия Бажанова
Редактор проекта, РМР, ICP-PPM
Устав проекта (Project Charter) – это документ, который обычно готовит руководитель проекта после получения вводных о проекте.
Зачем нужен устав проекта
Устав содержит основные характеристики проекта и согласуется основными заинтересованными лицами (как минимум – Заказчиком и Спонсором проекта). Как правило, разработка и подписание Устава несет в себе 3 основные функции:
- Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).
- Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.
- Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании).
Иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Хотя это не соответствует классической методологии, по которой устав готовится только для уже оцененного и утвержденного к реализации проекта.
Важно! Начинать работу по проекту без подписанного устава – это самая плохая услуга, которую можно оказать самому себе как руководителю проекта. Не определив и не согласовав цели и содержание того, что вы будете делать, вы рискуете очень быстро оказаться в ситуации, когда сроки прошли, бюджета закончился, сделано «не то и не там», а ваша карьера РМа в этой Компании бесславно закончилась. Более того, подписание устава у заинтересованных сторон – это отличный индикатор того, действительно ли они заинтересованные или просто делают вид. В случае, если проект спущен «сверху», Спонсор назначен, а Заказчик и сам не понимает, зачем ему это нужно – лучше постараться с этого проекта ноги унести, а если не получится – по крайней мере осознать, как не остаться в результате единственным виноватым за неуспех (об этом мы еще поговорим).
Как написать устав проекта
Содержание устава проекта часто зависит от специфики Компании. В качестве примера можно привести следующий набор разделов устава:
- Начальные условия (Project Background) – что привело к инициации проекта, входные условия, «боль» Заказчика.
- Цели и ожидания проекта (Project Objectives / Expectations) – чего мы хотим достичь на выходе. Это что-то должно быть измеримым (по SMART или как-то еще, неважно) и не допускать двойного толкования. Например, цель «сделать систему CRM, чтобы привлекать больше клиентов» – как-то не очень, правда? А вот «разработать и внедрить систему CRM для сотрудников отдела продаж Северо-Волжского филиала до 01.12.2015 для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года» – это уже немножко лучше.
- Содержание и результаты (Scope and deliverables) – что именно мы включаем в состав проекта и какие конкретные результаты получим? Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку (а может, и саму организованную с нуля поддержку). В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включить подраздел со списком того, что в содержание проекта не входит в явном виде (чтобы все это согласовали и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили).
- Ключевые требования и характеристики (Requirements and Characteristics) – то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть «Срок обучения сотрудника системе не должен превышать 1 рабочего дня», «Поддержка системы не должна быть дороже 200 000 р. в год», «В системе одновременно должно работать не менее 300 человек» и подобное.
- Бюджет и сроки (Cost and Timelines) – деньги, сроки и их взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию типа Бюджет-Содержание-Сроки. Т.е. потратить больше денег прямо никак нельзя, уменьшать получаемые результаты сильно нежелательно (но можно, в самом крайнем случае), и если надо ради первых двух пунктов увеличить срок – это ок. Часто тут многие зависают, мол, «да нам все важно!», но в правильно мире вы идете к Спонсору и спрашиваете его, если спонсор адекватен – у него это понимание приоритетов точно есть, и он поделится им с вами.
- Ключевые участники (Key Stakeholders) – основные заинтересованные лица, как минимум – Спонсор, Заказчик, те, кому придется делиться с вами ресурсами (в матричной структуре), ваш руководитель, держатель бюджета и т.д. Включать сюда всю компанию не стоит, просто подумайте и напишите: а) кто должен знать о проекте на этой стадии б) к чьему авторитету вам будет полезно апеллировать в ходе проекта
- Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – про эти вещи мы еще поговорим подробнее, но в целом цель включения их в устав проекта – донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. Ну и чтобы потом никто не говорил «а нам не сказали».
Пример из жизни! Давайте сделаем очень короткий устав проекта «Ремонт в квартире», как образец, а то теория – это хорошо, но не всегда понятно:
- Начальные условия – живу в квартире уже 15 лет, краска на потолке облупилась, батареи старые и вообще мне некомфортно. Я заказала дизайн-проект, мне нарисовали квартиру моей мечты, осталось только сделать.
- Цель – сделать ремонт в квартире площадью 65 метров в строгом соответствии с дизайн-проектом не позже чем к такому-то числу и не больше чем за такие-то деньги.
- Содержание и результаты (Scope and deliverables) – на выходе должны быть полностью замененные коммуникации (сантехника, электрика, отопление), новая входная дверь, новая сантехника, косметический ремонт (плитка в санузле, ламинат, обои и потолки во всех комнатах), заказанная и установленная кухня, полностью все освещение и вся мебель. Что не буду делать: отдирать стяжку пола (что ей стало-то за 15 лет), делать теплые полы и звукоизоляцию, и менять окна (они хорошие, только 2 года назад поставила).
- Ключевые требования и характеристики – все должно быть в строгом соответствии с дизайн-проектом (см.пачку приложенных чертежей и смету), если что-то сделать нельзя или дороже больше чем на 10% – надо согласовывать на семейном совете. Разводку электрики и сантехники надо согласовать с местным ЖЭКом.
- Бюджет и сроки (Cost and Timelines) – 2 млн. рублей на все, включая мебель и кухню (30% на черновую отделку и коммуникации, 20% на чистовую, включая сантехнику, 20% на кухню и 30% на мебель). Срок – максимум 4 месяца, т.к. мы всего на 4 месяца договорились к родителям переехать, в крайнем случае можно добавить еще 2 недели (поживем в гостинице). Приоритеты бюджет-качество-сроки (лучше в гостинице поживем, пока штукатурка будет сохнуть, но денег на тепловую пушку для сушки не выделим и клеить обои на мокрую штукатурку тоже не будем).
- Ключевые участники (Key Stakeholders) – я, муж, родители, бригада, с которой я уже договорилась, соседи (надо уточнить, когда у них дети спят), ЖЭК (с ними надо проект согласовать).
- Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks) – допущения: соседи нескандальные, работать можно весь световой день, бригада адекватная и не будет бухать на объекте, курс доллара глобально не вырастет и стройматериалы сильно не подорожают; ограничения: нельзя работать после 22.00, не могу приезжать контролировать работу в будни (работаю), первая выплата бригаде возможна только в апреле (закончится депозит, где деньги на ремонт лежат); риски: возможно, ошибочно посчитана смета и денег на все не хватит, в дизайн-проекте ошибка, такую перепланировку узаконить нельзя, т.е. придется ремонт останавливать и все переделывать.
Ну и напоследок. Меня часто спрашивают, насколько детальным должен быть устав проекта? Точного рецепта здесь нет, но в общем случае – детализация устава проекта должна быть такой, чтобы в случае какого-то серьезного запроса на изменение в проекте вы могли обратиться к уставу как к истине в последней инстанции и сказать «нет, мы это не делает, т.к. это не приближает нас к цели проекта или противоречит характеристикам результата». По большому счету, если проект дошел до такого состояния, что запросы на изменение с уставом уже не «бьются» – похоже, ваш проект закончился неудачей и его лучше закрыть, требования и ограничения пересмотреть и начать новый.
Мораль: устав даже на 1 страничке А4, подписанный заинтересованными лицами, лучше чем неподписанный на 5 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).
Конечно, в уставе проекта могут быть и другие пункты в зависимости от специфики проекта, в посте перечислен “кандидатский минимум”, сам документ можно и нужно переделывать под себя.
Всего за 99 руб вы можете скачать готовый детальный шаблон устава ИТ-проекта в docx. В готовом примере устава проекта вы найдете все необходимые пункты – от содержания проекта и описания ролей и обязанностей участников проекта до перечня типовых рисков. После оплаты на почту вы получите архив с шаблоном. Сэкономьте свое время, оно стоит намного дороже!
Скачайте готовый пример устава проекта и начните работать прямо сейчас вместо траты нескольких часов на поиск и написание типовых разделов.
Купить готовый шаблон Устава за 99 руб.
Рекомендуем! Также за 249 руб вы можете скачать набор из трех разных готовых шаблонов уставов ИТ-проектов в docx, в том числе – два расширенных примера готовых уставов проектов (для работы с подрядчиком/заказчиком) и один сокращенный пример готового устава проекта (для внутренних проектов). Набор примеров уставов поможет вам создать на их основе именно тот устав вашего проекта, который нужен именно вам!
Купить 3 готовых шаблона Устава за 249 руб.
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Еще статьи
Показать еще
комментарии
Подписаться на нашу рассылку
Еженедельная рассылка полезных материалов
Источник