Если договорная документация призвана распределить права и обязанности между заказчиком и подрядчиком, то устав проекта носит более глобальный характер, распределяя зоны ответственности участников еще и внутри организации-заказчика. Его часто называют конституцией проекта. Вы узнаете, для каких целей и как составляется устав проекта; значение ряда новых для вас терминов, которыми может оперировать IT-компания; как можно эффективнее контролировать и управлять разработкой, внедрением СЭД.
Нормативная база
Для начала обратимся к отечественным стандартам по управлению проектами:
- ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»,
- ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»,
- ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой».
В перечисленных стандартах устав проекта не упоминается вообще, а проектной документации посвящено несколько строк.
Теперь обратимся к PMBоK – это «Руководство к своду знаний по управлению проектами», на данный момент вышло уже пятое издание 2012 г. (Project Management Institute, Four Campus Boulevard, Newton Square, Pensylvania 19073-3299 USA/США). Методология PMI (PMBoK) располагается на 1-м месте по применению в нашей стране. И недаром – американцы пока продолжают «рулить» IT-технологиями. Итак, с точки зрения PMBоK:
-
устав проекта – документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и представляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта;
-
спонсор проекта – лицо (или группа лиц), предоставляющее ресурсы и поддержку для проекта и ответственное за достижение успеха.
PMBоK рекомендует определять и назначать руководителя проекта как можно быстрее, чтобы тот принял активное участие в разработке устава проекта. Но саму разработку устава PMBоK все-таки рекомендует выполнить спонсору проекта. В реальности все происходит иначе. И, как правило, разрабатывает этот устав исполняющая организация, учитывая, конечно, пожелания заказчика. Происходит это в том числе по причине нечеткого понимания заказчиком назначения и структуры устава, наличия большего опыта в этой сфере у IT-компании.
При разработке устава нужно стремиться учесть пожелания всех заинтересованных сторон. Это кажется парадоксальным, но, имея общую цель – создание уникального IT-продукта, каждая сторона проекта преследует свои интересы:
- спонсор – получить рабочую СЭД, опмизирующую деятельность заказчика, но сделать это подешевле и избежать незапланированных расходов;
- заказчик – получить необходимую ему СЭД и побыстрее, с минимумом усилий со стороны своего персонала;
- руководитель проекта – успешно реализовать проект, вырулив в конфликте интересов разных сторон;
- исполняющая организация – разработать систему, удовлетворяющую требованиям заказчика, затратив на это минимум своих ресурсов и за максимально возможную цену.
В общем, все непросто. Одна из основных задач устава – регламентировать взаимодействие сторон, определив и зафиксировав зоны компетенций и полномочия каждой. Ведь ни в каком ином проектном документе это не будет описано: договор между заказчиком и исполнителем фиксирует лишь отношения с внешней организацией в юридическом и финансовом аспекте; в техническом задании описаны требования к создаваемому продукту. В уставе же можно описать уровни управления проектом, порядок взаимодействия в случае изменения объема проекта, сроков, работу с проектными рисками и т.п.
Что внутри устава?
PMBоK рекомендует отразить в уставе проекта следующую информацию:
- назначение или обоснование проекта;
- измеримые цели проекта и соответствующие критерии успеха;
- высокоуровневные требования;
- допущения и ограничения;
- высокоуровневые описания и границы проекта;
- высокоуровневые риски;
- укрупненное расписание контрольных событий;
- укрупненный бюджет;
- список заинтересованных сторон;
- требования к одобрению проекта (т.е. что именно составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает акт приемки работ);
- назначенный руководитель проекта, сфера его ответственности и уровень полномочий;
- Ф.И.О. и полномочия спонсора или другого лица (лиц), авторизующего устав проекта.
Теперь более подробно рассмотрим примерную структуру...
