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

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

Сегодня в мире принято несколько стандартов, ориентированных на выполнение ИТ-проектов. Наиболее известными и популярными среди них являются PRINCE2 (Великобритания), PMBOK (США), V-Modell (Германия), P2M (Япония), Hermes (Швейцария) и пр. Однако в России эти стандарты, хотя и применяются (одни — широко, другие — редко), не носят официального характера. Это и послужило причиной для разработки первого национального стандарта ГОСТ Р 54869—2011 “Проектный менеджмент. Требования к управлению проектом”, утвержденного Федеральным агентством по техническому регулированию и метрологии в начале февраля текущего года.

Разработка стандарта была начата в 2008 г., для чего компания PM Expert и группа компаний “Проектная ПРАКТИКА” учредили Автономную некоммерческую организацию “Центр стандартизации управления проектами”. В работе над стандартом приняли участие специалисты российских компаний, специализирующихся в области проектного управления, а также профессионалы, состоящие в международных ассоциациях менеджеров проектов. ГОСТ Р 54869—2011 будет введен в действие в России с 1 сентября 2012 г.

Говоря об особенностях российского стандарта, директор департамента знаний, информации и методологии автономной некоммерческой организации “Оргкомитет Сочи 2014” Павел Алферов, принимавший участие в его разработке, выделил три момента. Во-первых, это краткость стандарта. Разработчики принципиально договорились не делать русскую версию американского национального стандарта PMBOK (Project Management Body of Knowledge), хотя сначала команда пошла именно по этому пути. Однако обсуждение затянулось, и было принято другое решение, заключающееся в том, что стандарт будет содержать только то, что обязательно должно присутствовать в проектной деятельности. Вторая особенность —универсальность, подразумевающая, что требования стандарта распространяются на управление любыми ИТ-проектами и могут быть применены для проектов, реализуемых как физическими, так и юридическими лицами, а также подрядчиками или исполнителями внутри организации. И третья особенность —ориентированность на результаты, означающая, что стандарт определяет только обязательные выходы процессов управления проектом, но не содержит требований к методам реализации этих процессов. Другими словами, стандарт отвечает на вопрос, что нужно делать, чтобы эффективно управлять проектами, но оставляет свободу выбора при ответе на вопрос, как это делать, подчеркнул г-н Алферов.

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

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

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

Согласно ГОСТ Р 54869—2011, управление проектом включает совокупность процессов инициации, планирования, организации исполнения, контроля и завершения проекта. Те же группы процессов используются во многих международных стандартах, в частности в американском PMBOK, так что в этом смысле российский аналог не стал чем-то особенным.

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

Процессы управления проектом

ГОСТ Р 54869—2011 описывает двенадцать процессов управления, восемь из которых — это процессы планирования проекта (рис. 2). Как отметил г-н Алферов, в стандарте их последовательность чётко не прописана, в каждом случае нужно исходить из логики проведения работ. Более того, каждый из шагов, которые предпринимаются для управления проектом, не является строго обязательным. Можно, например, не проводить операционные встречи, но тогда участники команды будут плохо взаимодействовать друг с другом. Можно даже не составлять план проекта, но тогда результат может оказаться не тем, как ожидалось.

Процесс инициации проекта

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

Процесс планирования содержания проекта

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

Процесс разработки расписания проекта

Реализация этого процесса позволяет выявить взаимосвязи между отдельными работами по проекту, провести оценку длительности всех работ по проекту, определить и утвердить график привлечения ресурсов, необходимых для выполнения проекта в срок, сформировать и задокументировать расписание проекта и, наконец, утвердить базовый календарный план проекта. Наиболее популярные продукты, которые могут использоваться для этих целей, — Microsoft Project, Visio, PowerPoint.

Процесс планирования бюджета проекта

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

Процесс планирования персонала проекта

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

Процесс планирования закупок в проекте

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

Процесс планирования реагирования на риски

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

Процесс планирования обмена информацией

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

Процесс планирования управления изменениями

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

Процесс организации исполнения проекта

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

Процесс контроля исполнения проекта

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

Процесс завершения проекта

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