Устав проекта по внедрению СЭД

Нормативная база

Для начала обратимся к отечественным стандартам по управлению проектами:

• ГОСТ Р 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 рекомендует отразить в уставе проекта следующую информацию:

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

Теперь более подробно рассмотрим примерную структуру...