Устав проекта (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 страничках. И требование подписать его до начала работ со стороны РМа полностью законно в любой компании, более того – это прибавляет вам профессионального веса, позволяет понять «а чего же мы все-таки делаем» и получить хоть какие-то полномочия. Если управление проектами в компании отсутствует как класс, то даже неподписанный устав лучше чем его отсутствие, вы хотя бы разберетесь, что делать, и настроитесь на правильный лад с самого начала проекта (да простит меня РМВОК).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

Внешние участники проекта внедрения
Предприятия	Директора предприятий Отдел по работе с персоналом Ключевые функциональные специалисты Пользователи
Информационные ресурсы	Информационное агентства Тематические порталы Управленческие журналы
Сообщества	Профессиональные сообщества Профессиональные организации
Мероприятия	Выставки Семинары Конференции
Консалтинг	Бизнес-консультанты Поставщики решений Специалисты по внедрению Интеграторы

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ Project Management Institute - www.pmi.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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