Руководства, Инструкции, Бланки

Образец Проекта Устава img-1

Образец Проекта Устава

Рейтинг: 4.2/5.0 (1724 проголосовавших)

Категория: Бланки/Образцы

Описание

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

Устав проекта пример. Скачать (MS Word)

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

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

СКАЧАТЬ
Устав проекта пример
MS Word

Так же читайте по теме Устав проекта:

Просмотры: 1 915

ПОПУЛЯРНЫЕ СТАТЬИ КРАСНЫЕ КНИГИ

Copyright © 2014-2016 forPM
info@forpm.ru

Другие статьи

Составление устава проекта

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

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

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

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

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

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

Шаг 1: Определите и наймите спонсора/поддержку проекта

Должен присутствовать хотя бы один коммерческий директор, который будет настолько заинтересован в проекте, чтобы быть готовым выполнять роль охранника капитала и представителя всей управленческой группы. Человек должен понимать нужды бизнеса и задачи проекта. Проблема появится в случае, если вы не можете найти такого человека - проекты выполняются (или должны быть выполнены) для достижения каких-либо целей в бизнесе. Если никто не заботится в достаточной степени о целях, то управление должно задаться вопросом о том, зачем проект вообще будет выполняться. Руководитель проекта иногда ставится в такое положение, но это не всегда является эффективным решением. На встрече руководства он будет выглядеть как официант в кафе ("Здравствуйте, меня зовут Дэйв, и я буду вашим официантом. руководителем проекта сегодня"). Если вы оказались вовлеченным в проект, который не имеет четкого спонсора/поддержку в руководстве, то наилучшим выходом будет нахождение такого человека. Без него вы очень скоро окажетесь в затруднительном положении. Очень редки случаи, когда руководитель проекта может противостоять требованиям руководства без того, чтобы отрицать все предлагаемые ими накладные действия.

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

Шаг 2: Назначить преданного своему делу руководителя проекта

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

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

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

Шаг 3: Задокументировать нужды бизнеса проекта.

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

Иногда коммерческие директора добровольно хотят быть спонсорами, потому что они хотят быть вовлечены в проект, обладающий большим значением в организации. В таком случае как может выжить при таких препятствиях, как сокращения или вступление на должность нового директора по информационным технологиям (CIO), который захочет рассмотреть каждый ИТ-проект до того, как заново задать приоритеты? Если потребности бизнеса были хорошо задокументированы, то даже руководитель проекта сможет объяснить их значение для организации.

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

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

Компоненты хорошего устава

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

Потребности бизнеса для проекта - как уже описывалось выше, это является ключевым аспектом устава. Без четко задокументированных нужд бизнеса проект будет плыть, как без компаса, в неведомых водах. Потребности бизнеса должны отражать тип выгоды, производимой проектом для организации, такой как, например, снижение затрат, увеличение прибыли либо увеличение потребительской удовлетворенности.
Экономическое обоснование проекта - оно должно переводить нужды в условные единицы (йены, евро, фунты, доллары, рубли и т.п.). Ваша организация должна иметь стандартный формат представления экономического обоснования проекта для того, чтобы оценивать несколько проектов при выборе.
Масштаб проекта на высоком уровне - данный пункт должен быть составлен из информации, собранной в основном от спонсоров проекта. Поскольку спонсоры материально поддерживают проект, то важно понимать их виденье проекта до того, как столкнетесь с «шипами» других участников. В то же время потребности бизнеса могут быть широки, а масштаб проекта может быть ограничен определенными областями.
Критические факторы успеха - определите и задокументируйте любые аспекты бизнеса, проекта, команды, расписания, комплектующих и т.д. что в случае невыполнения будет вредить успеху проекта. Хорошо понятые и задокументированные факторы успеха помогут в решении конфликтов во время продвижения проекта в случаях, когда необходимо будет сделать сложные решения относительно альтернатив масштаба, расписания, затрат или качества.
Ограничения и предположения - документируйте их всех на раннем этапе и возвращайтесь к ним на протяжении проекта. Ограничения и предположения должны быть на таких уровнях проекта, как ограничения по бюджету, сроки выполнения или требования к качеству.
Полномочия руководителя проекта - устав должен описывать ответственность руководителя проекта, уточнять его роль во взаимодействии с участниками проекта и организацией. Без такой документации полномочий проект будет зависеть от индивидуальных навыков руководителя. Если и существует такая должность, которая четко обеспечивает успешное завершение проекта, так это руководитель проекта.
Подписи - их сбор на уставе, скорее всего, выглядит как формальность, и обход этого, казалось бы, не будет иметь большого значения (аналогично составлению самого устава), но это далеко не так. Подпись в уставе представляет собой тот порог, который гласит, что человек прочел, понял и согласен со всей изложенной в уставе информацией. Без наличия подписи устав будет лишь одним из планировочных документов, который может быть, а может и не быть рассмотрен и ясен участникам. Как же участники, не связанные с текстом проекта, будут иметь четкое понимание важности проекта в организации, если не будет подписей спонсора и высшего руководства?

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

Похожие новости Комментарии (0)

Разработка устава проекта - Студопедия

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

Формирование бизнес-цели проекта

Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).

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

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

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

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

· стратегические и тактические цели организации-заказчика;

· формулировка требований организации-заказчика;

· ТЭО (технико-экономическое обоснование) ;

· внутрикорпоративная методология управления проектами и соответствующие политики.

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

В табл. 1.5 приведены требования к уставу проекта - перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

Таблица 1.5. Требования к уставу проекта


Рис. 1.2. Модель комплексного анализа участников и окружения проекта (Burnett, 1980). На рисунке ИКС - исследовательская команда спонсора

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

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

· все разделы предложенного формата устава проекта заполнены в соответствии с рекомендациями;

· в самом документе отсутствуют противоречия;

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

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

© studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам

Корпоративный университет

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

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

Полное наименование проекта

Краткое наименование проекта

Дата начала проекта

Дата завершения проекта

Благоприятствующие связи с проектами

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

Препятствующие связи с проектами

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

Критерии оценки успешной реализации проекта

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

Ожидаемые эффекты проекта

Объем проекта включает работы по проектированию, реализации и внедрению логически завершенных и взаимосвязанных функциональных блоков и компонентов продукта проекта и определяется в четырех ракурсах:
• Функциональный объем определяет функциональные характеристики внедряемого продукта. Решение об использовании той или иной функциональности продукта диктуется бизнес-процессами предприятия, на котором внедряются результаты проекта.
• Организационный объем, который определяется подразделениями предприятия – организационными единицами (отделами, конкретно определенными рабочими местами) внутри этих подразделений, охваченными внедрением продукта.
• Технический объем, который определяется требованием нормального функционирования продукта проекта в заданном функциональном и организационном объеме.
• Иной объем, который определяется требованиями по взаимодействию с другими продуктами на предприятии или другими требованиями, не входящими в состав функционального, организационного и технического объемов.

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

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

Организационная схема реализации проекта

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

Функциональная ответственность участников проектной команды

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

Перечень этапов работ и их результатов

Архитектор проектных решений

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

Решение проблем проекта

Процедуры управления проблемами проекта, состоят из следующих шагов:
• выявление и регистрация проблемы;
• определение ответственных за решение проблемы;
• определение необходимых действий для решения проблемы;
• регистрация результатов решения проблемы;
• отслеживание неразрешенных проблем.
Управление проблемами происходит на всем протяжении этапа реализации и мониторинга проекта.
Общую ответственность за управление процессом решения проблем проекта несет руководитель проекта.
Принятые проблемы рассматриваются на совещаниях по проблемным вопросам.
Ответственный сотрудник разрабатывает план мероприятий по решению проблемы и согласовывает его с руководителями проекта.
Решение проблемы может требовать изменения Устава проекта и Плана-графика проекта.

Copyright © 2015. Сайт создан при поддержке персонального сайта В.П.Лавущенко и ООО "Современные Интернет Технологии" Обратная связь: тел. (843) 567-12-56 (57, 58), e-mail: ec.univer@tatar.ru

Устав проекта (Project charter)

Устав проекта (Project charter)

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

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

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

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

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

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

Шаг 1: Определите и наймите спонсора/поддержку проекта

Должен присутствовать хотя бы один коммерческий директор, который будет настолько заинтересован в проекте, чтобы быть готовым выполнять роль охранника капитала и представителя всей управленческой группы. Человек должен понимать нужды бизнеса и задачи проекта. Проблема появится в случае, если вы не можете найти такого человека - проекты выполняются (или должны быть выполнены) для достижения каких-либо целей в бизнесе. Если никто не заботится в достаточной степени о целях, то управление должно задаться вопросом о том, зачем проект вообще будет выполняться. Руководитель проекта иногда ставится в такое положение, но это не всегда является эффективным решением. На встрече руководства он будет выглядеть как официант в кафе ("Здравствуйте, меня зовут Дэйв, и я буду вашим официантом. руководителем проекта сегодня"). Если вы оказались вовлеченным в проект, который не имеет четкого спонсора/поддержку в руководстве, то наилучшим выходом будет нахождение такого человека. Без него вы очень скоро окажетесь в затруднительном положении. Очень редки случаи, когда руководитель проекта может противостоять требованиям руководства без того, чтобы отрицать все предлагаемые ими накладные действия.

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

Шаг 2: Назначить преданного своему делу руководителя проекта

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

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

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

Шаг 3: Задокументировать нужды бизнеса проекта.

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

Иногда коммерческие директора добровольно хотят быть спонсорами, потому что они хотят быть вовлечены в проект, обладающий большим значением в организации. В таком случае как может выжить при таких препятствиях, как сокращения или вступление на должность нового директора по информационным технологиям (CIO), который захочет рассмотреть каждый ИТ-проект до того, как заново задать приоритеты? Если потребности бизнеса были хорошо задокументированы, то даже руководитель проекта сможет объяснить их значение для организации.

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

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

Компоненты хорошего устава

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

  • Потребности бизнеса для проекта - как уже описывалось выше, это является ключевым аспектом устава. Без четко задокументированных нужд бизнеса проект будет плыть, как без компаса, в неведомых водах. Потребности бизнеса должны отражать тип выгоды, производимой проектом для организации, такой как, например, снижение затрат, увеличение прибыли либо увеличение потребительской удовлетворенности.
  • Экономическое обоснование проекта - оно должно переводить нужды в условные единицы (йены, евро, фунты, доллары, рубли и т.п.). Ваша организация должна иметь стандартный формат представления экономического обоснования проекта для того, чтобы оценивать несколько проектов при выборе.
  • Масштаб проекта на высоком уровне - данный пункт должен быть составлен из информации, собранной в основном от спонсоров проекта. Поскольку спонсоры материально поддерживают проект, то важно понимать их виденье проекта до того, как столкнетесь с «шипами» других участников. В то же время потребности бизнеса могут быть широки, а масштаб проекта может быть ограничен определенными областями.
  • Критические факторы успеха - определите и задокументируйте любые аспекты бизнеса, проекта, команды, расписания, комплектующих и т.д. что в случае
    невыполнения будет вредить успеху проекта. Хорошо понятые и задокументированные факторы успеха помогут в решении конфликтов во время продвижения проекта в случаях, когда необходимо будет сделать сложные решения относительно альтернатив масштаба, расписания, затрат или качества.
  • Ограничения и предположения - документируйте их всех на раннем этапе и возвращайтесь к ним на протяжении проекта. Ограничения и предположения должны быть на таких уровнях проекта, как ограничения по бюджету, сроки выполнения или требования к качеству.
  • Полномочия руководителя проекта - устав должен описывать ответственность руководителя проекта, уточнять его роль во взаимодействии с участниками проекта и организацией. Без такой документации полномочий проект будет зависеть от индивидуальных навыков руководителя. Если и существует такая должность, которая четко обеспечивает успешное завершение проекта, так это руководитель проекта.
  • Подписи - их сбор на уставе, скорее всего, выглядит как формальность, и обход этого, казалось бы, не будет иметь большого значения (аналогично составлению самого устава), но это далеко не так. Подпись в уставе представляет собой тот порог, который гласит, что человек прочел, понял и согласен со всей изложенной в уставе информацией. Без наличия подписи устав будет лишь одним из планировочных документов, который может быть, а может и не быть рассмотрен и ясен участникам. Как же участники, не связанные с текстом проекта, будут иметь четкое понимание важности проекта в организации, если не будет подписей спонсора и высшего руководства?

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